Quoting Karoly Negyesi <karoly@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/