[development] Do not let postgresql hold back great patches

[Ivan Sergio Borgonovo]

On Fri, 16 Nov 2007 19:19:57 -0500
"Khalid Baheyeldin" <kb at 2bits.com> wrote:

> So, Karoly is proposing that we test on MySQL, then throw the issue
> over the fence to the folk who use (and care about) PostgreSQL for
> them to handle, because of the INSTALLED BASE issue, and the
> TESTING RESOURCES issue. This is NOT a technology issue.

That doesn't make it a good decision.
Again... putting aside the ignorance of someone about postgres,
forgetting completely the topic about what's better, *splitting*
support for the DB is not healthy for the project at this stage.

The path should be to make the DB abstraction layer more DB agnostic
and make developer more aware there is not just mysql.
Everything will look terrible if you design for mysql and then try to
port it to any other DB. This increase the inertia of moving to a
more agnostic DB layer and supporting anything else than mysql.

So "commit something, move on and let the postgresql people test/fix"
is not a solution. It is a dead end.
If the few pg people will stop to bother you at *every step* till we
won't have a DB abstraction layer and some way to deal with DB
sensible patches), mysql people will become even less aware there are
other DB. As a side note pg dev generally tend to know more about
mysql than mysql dev tend to know about pg.

When pg people will come out and say: "what kind of garbage did you
wrote? It can't be ported to pg unless we...." what you'll end up
with will be the mysql people saying "we can't mess with the code for
a DB that have just [put ridiculously low unsupported percentage
here] market share". And things will get worse.
It is NOT the way you build the premises for a decent SPI!

Larry Garfield made a good point too. But until you've the tools
(abstraction layer that should mitigate the problem quite
substantially and tune the patch system to make dev aware of "DB"
sensible patches) committing in the hope things will work on pg is
not going to make things better.

If you lower the support level for pgsql now you'll never have a sane
DB abstraction layer and sooner or later you'll support just one DB.

pgsql is just what we have... it could be anything else *reasonably
different* from mysql. Supporting 2 "anything" generally is not
enough to build up a sane SPI. What you end up is: case A is supported
and case B is special case of A, when you need to support case C
everything is so entangled that you realise trying to build a SPI that
way was wasted time.

Once drupal become a one db application it will be extremely hard to
go back.

This will "hold drupal back" much more than supporting pgsql upfront.

MS seemed to be interested in supporting drupal (is it?). They should
be interested to support MS SQL as well, that should help to have a
more agnostic db layer. (Larry... maybe they can give you a couple of
licenses of SQL 200X ;) but they won't provide the exorcist ).

As for me I installed D6 on pgsql. I'll try to learn how to
contribute the "drupalish" way (cvs, issues etc...).
I posted some patch for postgres mainly for modules in the past. I'll
try to help with beta and rc too.

As for the lower() problem I can't see why a "lowered" index can't
get in.

Again... it is a matter of good design and *freedom*.
Maybe mysql will be where pg is now, maybe it won't, maybe you can't
turn php into python in 1 or 2 years as you can't turn mysql in pg.
I don't care.
Fortunately we have mysql, and postgres and sqlite and firebird
and ... to chose from.
*************
It is not a matter of pg vs mysql.
*************
I don't want to bet on others projects blindly, I don't like
mono-cultures.

DB abstraction is a known problem and everybody know adding one more
layer has impact on performance. We have to live with it.

-- 
Ivan Sergio Borgonovo
http://www.webthatworks.it