[development] Do not let postgresql hold back great patches

Chris Johnson cxjohnson at gmail.com
Mon Nov 12 16:46:11 UTC 2007

A smattering of thoughts:

1.  Nice Catch-22 or Chicken-and-Egg situation we have here.  It's
sort of like the push for PHP5, only that kind of effort is more the
Postgres community camp.

2.  Not many Drupal sites use Postgres, so why support them?  Maybe
there would be more, if we supported Postgres.

3.  About the time MySQL reaches version 6, it will have roughly a
comparable feature set to Postgres 7 (more than 3 years old, now).

4.  For every feature we use that is easier or better in MySQL than in
Postgres, there are items that are easier or better in Postgres.  We
just haven't taken advantage of them.

5.  Not wanting to abstract the differences away between databases is
partially built upon the conceit that all Drupal developers are good
SQL developers as well.  In reality, the vast majority of us should
never write a line of SQL; instead we should be asking a Drupal API to
fetch/replace an object for us.  In practicality, that will never
happen, as it has adverse effects outside the quality of code (e.g.
the volume of code, novel new applications, etc.).

6.  Regarding previous remarks about the slippery slope and chx's
demand for some evidence:  you should know better, chx.  The evidence
is simple and obvious:  if we code specifically for one database (one
browser, one screen size, one RSS reader, one whatever), the effort to
then open up and use others at a later date is much larger than if we
always coded with that thought in mind.

My stomach hurts; I'm feeling grumpy.

Wasn't there once an effort to provide an sqlite version of Drupal?  :-)

More information about the development mailing list