PostgreSQL

THEORETICALLY you may be able to just replace the wp-db.php file with the PostgreSQL equivilent. Running of WP should be fine, but the installation or upgrade scripts may have MySQL specific functions in it. Database independence isn’t a terribly high priority at the moment because there really isn’t that demand for it. (You’re the first to even mention it.) Let us know how it goes.

the first ever? that seems odd, but i know i could deffinitely use the support, i already run postgres and theres no way i’d want to run both postgres and mysql. maybe others interested could coordinate some hacking on said wp-db.php file?

I’d certainly second the request… I may even try my hand at hacking the wp-db.php file this weekend.

I am the last ‘Anonymous’ poster. As a PostgreSQL user, I’ve always been a little frustrated by the lack of choice when it comes to blog code. It took a day or two, but I now have the CVS code working with PostgreSQL. There are quite a few MySQLisms that need fixing in the source and there are likely still a few quirks to iron out. I don’t actually have a MySQL install to compare with and the CVS code seems to change rather quickly. If anyone has a default install that I can tinker with, I’d be keen to compare. I realise that PostgreSQL operability isn’t high on the current development list; I am nevertheless interested in seeing some of these changes merged so that future WordPress users can choose between MySQL and PostgreSQL.
https://tulip.atm.ox.ac.uk/wordpress/
PHP 4.3.4, PostgreSQL 7.3.4
sql: https://tulip.atm.ox.ac.uk/wordpress/import.sql
cvs: https://tulip.atm.ox.ac.uk/wordpress/wp-cvs.tgz
NB: SQL above probably needs some additional indexes.

I’m rather curious.
Why not have a look at this:
ezSQL – is a widget that makes it ridiculously easy for you to use mySQL, Oracle8, InterBase/FireBird, PostgreSQL, SQLite (PHP), SQLite (C++) or MS-SQL database(s) within your PHP/C++ scripts (more db’s coming soon) – [Last Updated 25 Sep 2003].
Would this be good for WordPress if integrated? (Seems to be LGPL. I’m not very good at understanding these copyrights/licenses, so forgive me if this does conflict with the WordPress copyright/license.)

Aha. I did not know this. (Heh, I wouldn’t understand it, either. This is not my strong point.)
Is there a way to clean up the queries? Or were the non-standard queries used for a purpose, such as limiting the number of connect-and-query attempts (for things such as hosts who charge by the connect-and-query)?
If so, is there any way around this?
I hope you’ll forgive my curiosity. I just like to try to learn something every once in a while. ??

A quick example of such a query. In MySQL you can write:

SELECT * FROM table LIMIT offset, row_count

While PostgreSQL used to support such queries, but you must now write:

SELECT * FROM table LIMIT row_count OFFSET offset

There are plenty of examples. Do a diff on the source I posted and you’ll see many of them ??

randall
I share your frustration regarding postgres support. I would like to try out your work that you had linked above, but the files are no longer available. I tried to cvs the latest wordpress but I saw no indication of postgres support. Will you make them available again?
Thanks

This may be a totally noob question, but why aren’t we using PEAR::DB, PEAR::MDB, or ADOdb?
These libraries have the most activity and support (by a huge margin); and would go a long way to keeping MYSQL-only code out of this application.
I only have access to a box with PostgreSQL on it, and really would like to try wordpress out – but I don’t want to convert your database logic by hand just for the demo!

Sorry, I will try to put the code back up in a few days. It looks like I will have to take another CVS snapshot though as only a few of the SQL syntax changes I suggested made it in. To answer the last Anonymous question, using PEAR::DB and the will not help that much. The fact is that EZ-SQL abstracts the basics already. Both MySQL and PostgreSQL differ in their SQL statement syntax. As I posted above, a simple select statement that is valid in MySQL may not be valid in PostgreSQL and vise versa. It would be nice if everyone stuck to the SQL92 standards but they are pedantic and inefficient at times.

Ummm, just out of curiosity (using the LIMIT example) is there an SQL standard for this? Ooooh, I just did a bit of hunting and it appears that LIMIT isn’t a standard SQL keyword, which is why it’s implemented differently across different platforms. BAD database developers, BAD! *bops on the nose with a newspaper*

If limit is the main problem just write a method/function in the drivers like PEAR::(M)DB has:
function limitQuery(query, offset, rowcount)
All this does is get the parameters the right way round for MySQL/PostgreSQL and call the query method.
Of course you then have to emulate this for Oracle etc… but just supporting PostgreSQL would be a big step forward.
Peter

Randall, if you post your suggestions and code to the wiki they will be seriously considered for the next release.

There are a lot of changes to make and the old CVS code I had working is well out of date. I’m swamped with work at the moment but this is on my todo list… maybe in a few weeks.

ADOdb is the fastest of the abstraction layers, and it supports abstracting the offset/limit syntax. John Lim has a nice guide on the ADODB website for writing portable SQL.
-Dave