Countless times I needed to bother with PostgreSQL pecularities. I have nothing against PostgreSQL in a technical manner but neither the market nor our community has the human resources to support it. Let's face it: years come and go and the various PostgreSQL maintainers became busy with something else. This is not different from the outside world -- I can get highly professional MySQL help for a hundred bucks an hour, even our sysadmins know quite enough to get around with it but even when we payed three hundred bucks to the consultancy company one of the authors of pgsql, support still was lacking.
We have a horrible prospect on the horizon: supporting database system which are used by even smaller percentage of our community.
I am now officially against the pipe dream of database abstraction. It does not exist, SQL is just not standard enough despite all appearances. I want Drupal core to work with MySQL and that's it. Do you want to know the truth? This is already the state of affairs just noone admits it. Prove me wrong -- contact me if the number of hours you spent on testing Drupal 6 with PostgreSQL is bigger than twenty. Please be aware that I will probably publish your email.
We need to keep our db_* functions so if you want to do something different in a contrib database driver, then you can. We might want to use PDO to make the contrib authors' work easier, our system better (by standardizing on placeholders), but I do not want to do any more work because we pretend to support other databases. Use preg_replace on the queries or whatever, I do not want to care any more.
O.k. one I am biased o.k., I run www.commandprompt.com. No I wasn't the company that was paid, if I was it would have been done right. However, I have many customers running Drupal, and guess what? All on PostgreSQL. I have customers that are literally doing over 100 million transactions a day with Drupal and PostgreSQL.
I don't doubt that there is probably 90% mySQL installations out there but the 10% that are running PostgreSQL are high velocity, large installations that mySQL just couldn't handle. (I am not bashing MySQL just stating some particular strengths PostgreSQL has).
I also agree that database abstraction is difficult. I even reviewed the upcoming DB class for 6.0 at Dries request to help.
I think that if some of the Drupal community leaders came to some PostgreSQL community members and actually asked for help that you would get that help. We see some user requests but not much else.
I think Drupal6 is a very important release for Postgres and similar systems. Most contrib modules will finally ship with working schemas for these systems. This makes it practical to run a site on postgres. So I think we are making great progress toward friendliness toward mysql alternatives and i hate to see that slow down.
I agree that we need embrace optimizations for individual DBMS when appropriate. I am not a purist requiring exact same queries on all platforms. But that doesn't negate my point above.
Drupal 6 will see more pgsql adoption, thus more testing.
I agree with Moshe. I have only been following at a distance, but the efforts of Edison Wong in this direction seem to be particularly noteworthy and positive.
Edison Wong in the first place broke drupal_access_denied with his patch which was not needed for anything in core and then he closed the bug report that it's broken in favor of a feature patch. That was the very issue that sparkled this writing. If supporting these databases break core, then I am squarely opposed to them.
Again, let the guys do whatever they want in contrib and leave core alone. I am in support of PDO to make their work easier but I do not want to waste my time ever again chasing down a similar issue.
I agree 100%.
My biggest gripe with Drupal is that it tries to be *too* flexible. Core itself, contrib modules, everything has to work with everything else, and on top of that do your laundry, mow the lawn, and get you a beer. And oh, it has to work with every known database out there too.
Seriously, this slows down development, introduces new bugs, and bloats core.
I'm very much in favor of making Drupal LESS FLEXIBLE if it improves the common 80% case significantly. And it does... I have a number of highly modified Drupal cores that do just this and I couldn't be happier.
It's been said that Drupal doesn't want bloat in core, but if it wants to be extremely flexible, it's going to have bloat. It's going to have hacks. Every system is different, why should Drupal make up for the limitations of every system?
I would be surprised if there would be more than ten percent who runs postgresql -- could be as low as five. With MySQL 5.0 (and soon 5.1), the incentives to use PostgreSQL are less and less.
Dear chx and m3avrck,
<rant>
I understand where you are coming from. As you know (well at least Ted does) I have worked on some pretty large Drupal sites and have really struggled with performance tuning Drupal. However, I come from a different side of Drupal than both of you. I work on other peoples code. We build large Drupal deployments for some of the biggest companies using Drupal (IBM, Sony BMG, LifetimeTV.com, Best Buy, etc). We don't get the distinction of having one code base to use. We have to walk into every project and be prepared to tune whatever system the client dictates.
I don't pretend to know everything about either of your projects, but I do know that both of you currently work for companies that work on a single code base for Drupal. So you are able to tune Drupal for your needs for your site, with your hardware, and your database choice. So you want to impose your choice for your respective businesses on everyone else because of what your needs are? That seems short sighted to me. What is best for consumers in general is to be able to have choice. It is the crux of what the open source mentality is about to me. Freedom. The fact that I don't have to be locked into ANYTHING I don't want to. I have _freedom_ to choose my database platform, and I have _freedom_ to give my code back to the community. If my client wants to use Oracle, then they will and we will support them and help the community learn how to write SQL that is safe for oracle as well.
OR, maybe we lift the facade of database abstraction and actually abstract it. Maybe we stop kidding ourselves that mysql_query^H^H^H^H^H^H^H db_query is actually abstracted and look at how we can make Drupal better.
I find it worse chx, that someone who is a genuine leader / superstar in this community like yourself, is posting things like this to dissuade and discount the hard work by others to move to supporting additional databases. All the work done by folks to patch modules to work with postgresql and oracle removed simply because we are meeting the needs of the 80% mark?
My proposal is that we work with Larry Garfield et al. to come up with a new way of dealing with database abstraction for Drupal 7. Let's make something great instead of settling for something that works for most people. As Drupal becomes embraced by corporate IT departments, there are going to become more and more people using Drupal with MSSQL or Oracle or whatever database they have to. They often do not have a choice. We need to offer choice. And the attitude of, "well write the patch and send it in" does not work here. We need a stable platform for everyone, not just to fill our personal business goals.
</rant>
Steve Rude