[development] Do not let postgresql hold back great patches

Earnie Boyd earnie at users.sourceforge.net
Mon Nov 12 13:29:34 UTC 2007


Quoting Karoly Negyesi <karoly at negyesi.net>:

>>  I would think this is a slippery slope, making sure a patch work against
>> at least 2 db backends in a reasonable way is an important indication of
>> quality
>
> If pigs can fly they are better animals.Maybe you want to support 
> your statement with something.
>
> Though I said that "has a decent hope (use common sense) to work on 
> postgresql". Once it's committed those who care about postgresql, if
>
>
>> We introduced schema changes just because PostgreSQL cannot do case 
>> insensitive
>> matching by default, while MySQL works fine. For the sake of 5% (or 
>> 1%) of the sites,
>> we are increasing complexity.
>
> Amen brother. I am happy which simply removes LOWER from those 
> queries and kicks the ball to the postgresql half of the playground. 
> As I stated on my blog I have nothing against posgresql just I do not 
> want to deal / held back with it. Any support for this solution?
>

IMO, we need to focus on Drupal SQL[1] and not MySql SQL or Postgresql 
SQL or Oracle SQL for coding purposes.  Another layer of abstraction 
handles the nitty gritty of each different DB.  AFAIR, the code prior 
to 6 was both MySql and PgSql friendly.  So making a change in a 
different direction for Drupal 6 doesn't seem TRT to me.  However if 
Drupal 5 wasn't as PgSql friendly as I remember then I agree with 
Karoly.  For Drupal 7 I would like to see Drupal SQL handle all of the 
syntax changes needed for various DB engines; that means no more 
testing of $db_type outside of the Drupal SQL abstraction.  Then a 
company with Oracle, Sybase and DB2 could display data from all three 
database types comfortably with Drupal.

[1] http://drupal.org/node/191486

Earnie -- http://for-my-kids.com/
-- http://give-me-an-offer.com/



More information about the development mailing list