One the the biggest obstacles in Drupal development for PostgreSQL is that Drupal development is MySQL based with addtional support for other databases. This means usally, all the optimizations for Drupal are for MySQL, and this can often turn to be a de-optimization for PostgreSQL.

In the time I've spent developing on Drupal and as one of the Drupal PostgreSQL maintainers, I spend most of my time fixing the PostgreSQL driver when a new feature has been implemented and doesn't work on PostgreSQL. Quite often this means making PostgreSQL work like MySQL.

I have yet to see MySQL change its driver for a PostgreSQL optimization.

In Drupal 7, DBTNG was implemented which was a new object orientated database abstraction layer which goals were to make development less database focused in the sense that using DBTNG would prevent database bias code. However, edge cases, time and time again seem to crop up and still use database specific code. To top that off, DBTNG used the PHP PDO framework which used prepared statements and implemented PDO drivers for each database type in Drupal. Unfortunately, there have been inconsistantcies between the drivers, and PostgreSQL has suffered as a result. It would seem that PDO was developed with MySQL in mind.

This week at Catalyst IT we decided to start having fortnightly code sprints to help improve the development for PostgreSQL in Drupal. The basic idea is that, with more presense from PostgreSQL people in the Drupal community, PostgreSQL development will become much stronger.

So this friday, 10th of July 2009 will be our first PostgreSQL sprint in Drupal. We'll be in #drupal IRC on freenode.net come along if you want to help out @ 4pm +1200 GMT (New Zealand time)

We'll look at the a list of issues surrounding PostgreSQL and make a push to make it work!