[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