WordPress-Pg v1.2-1.1

Sloppily ported to PostgreSQL by Keenan Tims (ktims@gotroot.ca). Source codebase is the stable release of WordPress 1.2.

For those so inclined, donations are accepted via PayPal with the address ktims@gotroot.ca

WordPress version 1.2 PostgreSQL port version 1.1

System requirements:

Installation Instructions:

Generally, following the WordPress documentation will be fine. Specifically:

  1. Unzip/Untar the package into an empty directory.
  2. Open wp-config-sample.php and modify with your database connection details.
  3. Save this file as wp-config.php
  4. Launch /wp-admin/install.php in your browser of choice. This will initialize the database tables required for WordPress-Pg.
  5. Note the password given to you.
  6. [Optional] Follow the steps below for converting from MySQL-based WordPress
  7. Profit???

MySQL Conversion Instructions:

  1. Back-up your existing MySQL database. The script doesn't touch it, but better safe than sorry.
  2. Edit convertfrommysql.pl and configure database access details
  3. Run convertfrommysql.pl on a shell. *be advised that this will purge all records in the existing tables in PostgreSQL. Your MySQL tables will be unaffected. There are no guarantees, however.

User Notes (read these)

The WordPress developers have opted to use some capitalized fields in function names and MySQL table definitions. PostgreSQL and PHP are case sensitive, however columns in PostgreSQL are automatically made lowercase. Thus, many templates and plugins may have problems due to the case discrepancies. This has (so far) been reported to break custom wp-comments.php implementations, but I suspect this problem manifests itself elsewhere as well. As the only way to solve this would be a change in WordPress, there's nothing I can do about it. If you run into this issue, just searching for 'ID' and 'IP' and replacing them with 'id' and 'ip' in the plugin or template should solve the problem. If it doesn't, feel free to contact me.

It has also been reported that OSX's builds of PHP and Postgres don't include the pgaffectedrows() function which is called in ezSQL. I haven't had a chance to look in-depth into whether removing the call would cause any problems but I don't think it would. My recommendation is to find builds that include this function, but if that's beyond your means, commenting out the call to the problem function shouldn't cause anything to blow up. No guarantees.

Status:

Changes 1.1

Bugs:

I'm not aware of any bugs in the current implementation (specific to WordPress-Pg; general WordPress bugs should be directed at the WordPress developers). If there are bugs, they are likely date-related, or portions of WordPress code that don't honour referential integrity. Such code is (generally) easy to fix. Bug reports are greatly appreciated, preferably with a repeatable scenario for recreating the bug on a fresh install.

Features:

Everything in WordPress base should work fine in this version. Plugins (including the included ones) are untested and may or may not work.

Testing:

Testing platform:

Tested features:

Untested features:

Removed features:

PostgreSQL porting notes:

The database schema has remained virtually unchanged from the MySQL schema. Some rudimentary (and insufficient) referential integrity checking has been added, however, some MySQL-isms remain hacked in (enums are implemented with a simple constraint on a text field). This decision was made to ease the transition from MySQL and to make the job of porting simpler. In the future, WordPress-Pg may be upgraded to have full referential integrity checking and the removal of denormalized enums. Functionally, this shouldn't be an issue for most users. Beware that some scripts or plugins that manipulate the database directly may cause errors if they violate referential integrity.

Ports of future versions of WordPress will be done from scratch, rather than by merging changes. Hopefully the WordPress team rectifies the horrible mess that is the installation scripts so that the process isn't quite as onerous the next time around. The only changes made to WordPress code will be made to the DB access and related code. No bugfixes or patches will be applied save for those that fix bugs in the PostgreSQL port or improve referential integrity or normalization. These fixes should apply exclusively to embedded SQL code whenever possible.

It would be nice to have a properly abstracted version utilizing PostgreSQL's superiour featureset, such as views and stored procedures. This would greatly simplify the code embedded in WordPress. I'd also like to see WordPress use something more robust than ezSQL, like PEAR DB or ADODB. ezSQL is rudimentary and doesn't provide much abstraction (or even parameterized execution). On the way there, they should properly abstract the DB. Embedded SQL is a horror to port and difficult to maintain. It's also good place to start on OOizing WordPress. However, the amount of work required is huge, and many scripts would have to be rewritten from scratch. In the meantime, this version will suffice to offer an alternative to MySQL for those that need it. To the best of my knowledge, it is a fully-featured port.