Almost every developer know that there is an other Open Source Database Server besides MySQL; her name is PostgreSQL. She is a good option if you are planning a scalable website with high traffic or specific transactions (e.g. e-commerce, large community sites). There are more advantages but my aim here is not a list of "top ten list of ... ".
I'd like to make a tiny proposal that could end with a Common Recommendation to Drupal coders.
Why Drupal coders?
Drupal core (4.7.x and CVS) is fully PostgreSQL compliant. Amazing! But prepare the pain contributed modules can cause:
- no PostgreSQL scheme attached
- module installers without PostgreSQL option
- PostgreSQL un-compliant SQL queries
I think Drupal coders (contributors etc.) need a Recommendation of how to handle the minimum standards of PostgreSQL compliance while Drupal end users need more patience :)
Comments are welcome.
Comments
DBA
There are a lot of forum posts and issues on drupal.org dealing with database abstraction issues. I'm also a Postgres fanatic, but a lot of people want to use Oracle, and some might prefer e.g. the Firebird DB, which is nearly as free as Postgres.
Could I suggest changing this group to a "Database Abstraction" group instead of simply a Postgres group? A true DB abstraction layer would allow the removal of MySQL-specific syntax from core and contributed modules, and then Postgres (and every other DBMS) would be well-supported without having to rewrite the SQL for all contrib modules.
Also, I get the sense it would be easier to rally developers around database abstraction than a Postgres push. Perhaps work could focus on writing a Drupal Enhancement Proposal (DEP) for a DBA layer; if implemented, it would become the de facto standard for module developers and there would be no need to enforce Postgres-compliant coding behaviour on contributors.