Is there anyway to use wordpress with PostgreSQL rather than MySQL?
Is there anyway to use wordpress with PostgreSQL rather than MySQL?
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.
PHP 4.3.4, PostgreSQL 7.3.4
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 ;)
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?
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.
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.
I'm familiar with ADOdb and it is useful. Migrating from EzSQL to ADOdb would take a concerted effort from all developers. As it stands, the EZSQL interface is used which does provide adequate abstraction. However, writing portable SQL is not trivial as
http://php.weblogs.com/portable_sql suggests. Again, this would require a great deal of effort. I think the only way it would get done is if the maintainer sees it as a priority.
Well, since I am the other odd-ball wanting to get this running on a non-MySQL DB (SQL2K in my case), I'd be willing to spend some time working on developing a generic DB solution.
Having a quick glance at the code, it does not seem that the SQL is all that complex and could indeed be abstracted to work with any number of DBs.
*Frustrated* Now that Movabletype has gone Micro$oft I'm looking for a tool that can do the same or more... Word Press is the closest yet, but I need support for PostgreSQL. My serveradmin won't install MySQL at all :( I really hope that there will be PostgreSQL-support for WordPress SOON!
Kristine S. Dufey
Ditto. PostgreSQL is the best free database. WP should support it.
In fact, I'll go an extra step - I'll donate $50 the day a WP release supports PostgreSQL as an equal alternative to MySQL.
Anyone else reading this who wants PostgreSQL support should start posting pledges here. Money talks.
I would also like to put in a request for PostgreSQL support. If WP is to be an attractive MovableType alternative -- especially in light of MT's new licensing scheme -- it should try to mirror as many support features as possible, including choice of database backends.
Hopefully WP will generate more developer interest so that this can happen.
... in strange ways.
(just kidding, but it is an Anonymous $50 pledge ;) )
I am sure that some wordpress user/developer will certainly take this up, and make it happen.
Isn't itch-scratch the best part of open source ? :)
Yeah, I just made my server's admin jump three different types of hoops to install MySQL, where there's a perfectly good PostgreSQL already installed...
Add another to the list of those interested in PostgreSQL. I avoid mysql as much as possible - to the extent that I often won't use a product that exclusively uses it.
Is there going to be PostgreSQL support in the near future?
Is there a central place where the development of a general DB solution is happening? I want to lend a hand but don't want to necessarily re-work the same portion of code that has already been generalized. I would appreciate it if someone could point me in the right direction.
Unfortunately, there is no centralised place. It should probably be a CVS branch but you'll need to pester a core developer for that. My various hacks at getting wordpress to use PostgreSQL have royally hosed the ability to use MySQL. If the developers would stick to reasonably standard SQL statements, the port would be trivial... I've more or less given up on getting the current version of wordpress working with PostgreSQL. I figure it would take about 1-2 weeks (f/t) to get the code working with PG again, and probably another to get it working with both. For me, my ancient, 'alpha code' works well enough.
Bugzilla has been working on succh issue for 3 years now, You might want to peek at their code
WordPress uses ezSQL which has a Postgres version. So drop that in instead of wp-db.php. Next it is a matter of determining which SQL gives Postgres problems, and how we could work around that. These problem areas could be listed on the wiki.
This topic has been closed to new replies.