[development] Do not let postgresql hold back great patches

Ivan Sergio Borgonovo mail at webthatworks.it
Mon Nov 12 11:34:33 UTC 2007

On Sun, 11 Nov 2007 20:14:30 -0600
George Kappel <gkappel at herrspacific.com> wrote:

> 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


I think supporting one DB is not just a matter of losing support but
it is a matter of loosing freedom. Once drupal lose the
infrastructure for DB independence, it will be hard to put it back.

Support for 2 DB is actually too few to keep the code sane. The
second will just be a special case of the first rather than an

I am *ing scared of mono-cultures.

No one said DB abstraction had to be easy, actually it isn't and
there are plenty of DB abstraction layers out there to prove it.

I was actually looking at http://www.sqlalchemy.org/ (python) to
learn something.
Any chance we could introduce, get inspired, rely on an existent DB
abstraction layer?

OK, I'll stop to pretend to be a software architect and I'm going to
install D6 on pgsql now to see if I can help in anyway. Installation

BTW I've some older drupal sites on pgsql. The reasons I chose pgsql
were historical (more mature transaction, stored procedures...).
If I'd have to chose for the future I *may* reconsider to use mysql.
All my pgsql sites are running smoothly even if I had to patch some
modules. I could live with a mysql only D6. I'd just consider it
risky for the future of drupal itself.

Wasn't Microsoft interested in supporting drupal running on IIS/MSSQL?



BTW as far as I know there is no way to introduce a unique constraint
in pgsql without eliminating the duplicates first.

For the case exposed here http://drupal.org/node/146466

ALTER IGNORE TABLE {search_index} ADD UNIQUE KEY sid_word_type (sid,
word, type)");
ALTER IGNORE TABLE {search_dataset} ADD UNIQUE KEY sid_type (sid,

would turn to be

delete from {search_index}
  where exists ( select 'x' 
    from {search_index} i
        i.sid = {search_index}.sid
        and i.word = {search_index}.word
        and i.type = {search_index}.type
        and i.oid < {search_index}.oid

alter table {search_index}
  add constraint sid_word_type
  unique (sid, word, type);

delete from {search_dataset}
  where exists ( select 'x'
    from {search_dataset} i
        and i.type = {search_dataset}.type
        and i.oid < {search_dataset}.oid

alter table {search_dataset}
  add constraint sid_type
  unique (sid, type);

untested on drupal... tested on a *test* table, going to test further

(oid is a bit of pgmagic, oid is the object id, so you're not risking
to kill all the row and leave at least one instance).

Ivan Sergio Borgonovo

More information about the development mailing list