• The EXECUTE USING feature in PostgreSQL 8.4 will allow the use of more secure dynamic SQL in PL/PgSQL.

• User defined exceptions in PostgreSQL 8.4 are a very exciting feature to me. In our unit tests we often check if an exception is properly raised. However, for exception that we raise ourselves, we’ve never been able to check which exception is raised.

  Another exciting possibility is that this will allow us to come up with a very clean validation scheme that produces exceptions that we’ll be able to use in the client web GUI.

• WITH queries in PostgreSQL 8.4 will allow some very cool things, the coolest of which is something that I’ve wished for on more than one occasion: recursion.

• The introduction of proper support for the SQL standard XML Type makes me wish that my favorite web hosting provider would support a real database besides their standard MySQL offering.

• Enumerated Types will make some of my table definitions slightly clearer.

  -- This isn't too shabby (thanks to the CHECK constraint):
  CREATE TABLE persons (
  the_gender CHAR(1) CHECK (gender = 'm' OR gender = 'f')
  );
   
  -- But, I like this much better:
  CREATE TYPE gender AS ENUM ('male', 'female');
  CREATE TABLE persons (
  the_gender gender
  );

Extra kudos to the PostgreSQL development team for their accelerating pace!

There are four postgresql backends:

• ruby-postgres. This version is no longer maintained. This is the version we used when the project began.
• postgres-pr. This is a pure ruby implementation, which is not interesting for us.
• postgres. This is the continuation of the unmaintained ruby-postgres. This version includes such fixes as that it can be compiled against libpg-8.3.
• ruby-pg. It is said that this one is now the official postgres back-end, but when I install it, the application still can’t find “postgres”.

Because the aforementioned article states that the pg extension is unstable, “postgres” seems to be what we should use. The article states that it is included in the ruby-pg package, but it doesn’t work when I install it, so I had to install “postgres”. I uninstalled ruby-pg, because it doesn’t seem necessary.

To continue, we once used a patched postgresql adapter, because we needed more accurate timestamps (the standard connection adapter rounded everything off to whole seconds), but if I recall correctly, this patch was only necessary on the connection adapter in Rails, not the back-end. We never commissioned the functionality that required this, so this existed only in the workdir of one of the devs.

As a final note; on our production server, we have a version of ruby-postgres installed in /usr/local. I can’t remember why…

Using this plugin, the user is asked for his or her credentials using a HTTP Basic authentication challenge. (The code for this is adapted from Coda Hale‘s Basic HTTP authentication plugin.) It’s possible to specify a guest_username in the database.yml which will be used as a fall-back if no credentials are supplied. After successful login or if a guest user is found, the plugin will make sure that all database operations run as that user. If any operation fails due to insufficient user rights, the user will be prompted for a username/password pair again.

Detailed and up-to-date documentation for the plugin can always be found at the plugin’s homepage. Go to the plugin’s project page for getting help or for reporting issues with the plugin.

This motivated me to take a closer look at PostgreSQL’s documentation on unique indexes:

Note: The preferred way to add a unique constraint to a table is ALTER TABLE ... ADD CONSTRAINT. The use of indexes to enforce unique constraints could be considered an implementation detail that should not be accessed directly. One should, however, be aware that there’s no need to manually create indexes on unique columns; doing so would just duplicate the automatically-created index.

Grepping for CREATE UNIQUE INDEX in our migration history quickly revealed that the index which lacked an accompanying constraint was indeed created by CREATE UNIQUE INDEX instead of by ALTER TABLE ... ADD CONSTRAINT. So, now I know that, indeed, I have to use ALTER TABLE ... ADD CONSTRAINT instead of CREATE UNIQUE INDEX to add unique constraints with accompanying indexes to existing tables.