On Fri, 16 Nov 2007 19:19:57 -0500 "Khalid Baheyeldin" <kb@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