Postgres support is very very far from high priority, but when we do have it, it would make more sense to maintain 1 provision_db_server module that extends drupal's existing db api. ie: provision.mysql.inc and provision.pgsql.inc.
even less of a higher priority is multiple web server (ie: apache/lightppd etc) support, but something similar could be useful if we wanted to implement multiple TYPES of apache hosting (ie: clusters, web front ends, etc).
Comments
Comment #1
anarcat commentedMake it clear that we want to abstract the database layer here.
Comment #2
adrian commentedThis can't be done until we're on D7 with the new db layer.
so this is a very very long time away.
Comment #3
adrian commentedWe now no longer rely on the drupal database layer at all, and drush 2.x now requires php 5.2, so we can rely on PDO always being available.
The only functions that need to differ for PG are :
At least for D6 sites, this should allow us to have full postgres support for drupal (in as far as the drupal postgres port actually works).
This would also give us access to sqlite, which might be useful for some interesting problems.
Comment #4
anarcat commentedTagging for 0.4.
Comment #5
anarcat commentedThis is a requirement of #585796: postgresql backend support.
Comment #6
mradcliffeMain purpose of this post is to subscribe to get this into my issue queue.
I think a small provisionPDO class might be sufficient (not extending PDO itself). The constructor and destructor can handle a connection with other methods such as query, results, db_exists (?), create/drop_db, grant/revoke, and some others.
Comment #7
adrian commentedwe need to move them into drush engines, and conditionally include them based on a flag.
i'm open to making them classes too.
in fact, this might help a lot in our future work for server stuff.
Comment #8
adrian commentedthis is done in dev-services.