[development] So why we do support postgresql?

Larry Garfield larry at garfieldtech.com
Wed Jan 16 06:55:07 UTC 2008


I have to recall something Jeff Eaton said to me over dinner a few months ago:

Drupal supports multiple theme engines.  Now, it's not like anyone uses 
engines other than phptemplate these days.  I suspect the percentages for 
Smarty and Tal are in the same ballpark as those using Postgres.  However, 
making sure that we support multiple engines forces us to make certain design 
decisions that in the long run are good architecturally.  Database 
abstraction is the same logic.  Forcing ourselves to think generically about 
databases forces us to make certain design decisions that, in the long run, 
are good for the health of the code, even if only 5 people use something 
other than MySQL.

So the question is, how can we make supporting other databases easier, so that 
we don't accidentally break things or have patches languish for weeks?

- Schema API should help a great deal here.

- Hopefully the database work I'm doing in Drupal 7 should help under the 
hood.

- Automated unit testing of core helps a lot of things.  If we can run unit 
tests against both MySQL and Postgres, that would help find bugs earlier.

- I like the proposal for flagging issues as "Hey, Postgres people, take a 
look".  That would be much more "up front" and get noticed by more people, 
which in turn would, hopefully, mean more Postgres people able to test things 
or offer input.  (I didn't know there was a wiki page until earlier today, 
either.)

- Other ideas?  Remember, we'd want to do this for every database we support.

As for chx's actual proposal, to let patches through if they work on MySQL and 
Postgres testing is not forthcoming, I'm torn.  On the one hand, yes, scratch 
your itch.  On the other, if we start committing patches that don't work in 
Postgres then we soon don't actually work on Postgres and it's just that much 
more work later.  I'm torn here.

I could see accepting patches that work in both but are sub-optimal in 
Postgres, eg notably slower but still functional.  Improving the Postgres 
performance of that query then becomes a task for someone with an itch, but 
we still run on all "supported" databases.

On Tuesday 15 January 2008, Karoly Negyesi wrote:
> Hi,
>
> Still there are no testers. I want to reiterate my plea: make
> postgresql support somewhat optional. If there are testers, great, if
> not, go on with life. You can flame me, but this is already the state
> of affairs just noone wants to admit. Just see
> http://groups.drupal.org/node/6980 . Greg spoonfeeds you. I know we
> will get testers for the rest of the week because of this letter and
> then they will move away as it happened uncounted times.
>
> I wonder what people will say. "Monoculture is bad" -- tick, do not
> bother with this answer. "You are evil" -- tick, do not bother either.
> "There are testers, but" -- surely there are just they have hidden
> themselves really well. What about answering something constructive? I
> *am* bored by needing this raised every month.
>
> Regards
>
> Karoly Negyesi


-- 
Larry Garfield			AIM: LOLG42
larry at garfieldtech.com		ICQ: 6817012

"If nature has made any one thing less susceptible than all others of 
exclusive property, it is the action of the thinking power called an idea, 
which an individual may exclusively possess as long as he keeps it to 
himself; but the moment it is divulged, it forces itself into the possession 
of every one, and the receiver cannot dispossess himself of it."  -- Thomas 
Jefferson


More information about the development mailing list