Most of my database tables always have four columns in common:

created_on timestamp
created_by_id int
last_modified_on timestamp
last_modified_by_id int

These columns should be pretty self explanatory. Usually created_on has a default of now() to auto populate it. Populating the last_modified_on column is a little more difficult, especially if you don’t want it to be populated on INSERT (which is what using default now()) would do.

Of course we could just provide for it in our code, especially if using a trusty application framework that takes care of it for us, but I like putting basic logic in the database, and we can’t assume all data updates will come from our application. They could, for example, come from a command line update.

I crafted this quick little database trigger function for taking care of this for me:

CREATE OR REPLACE FUNCTION auto_update_last_modified()
  RETURNS TRIGGER AS
$BODY$
DECLARE
BEGIN
	NEW.last_modified_on:= now();
 
	RETURN NEW;
END;
$BODY$
  LANGUAGE 'plpgsql';

This function simply populates the last_modified_on column of NEW (the new record being updated) with the current timestamp. Now I can add a trigger to every table that has this column:

CREATE TRIGGER auto_update_table_name_last_modified
  BEFORE UPDATE
  ON table_name
  FOR EACH ROW
  EXECUTE PROCEDURE auto_update_last_modified();

And now when updating a record in table_name, it will automatically populate a value for last_modified_on.

A new version of PostgreSQL, 8.4.2-r1, is available in Gentoo Portage, but be careful. It appears the server is compiled with HAVE_INT64_TIMESTAMP by default, something not true with previous versions. Because of this, after updating, you might get an error about the data cluster being incompatibile with the server when you restart, unless you were using the pg-intdatetime use flag in previous versions (which has been removed in the newest version).

Continued…

Another cool feature I’ve recently discovered in PostgreSQL, although one available and documented for a long time, is table inheritance, which works almost exactly like object inheritance in object oriented programming. This simply means that you can have tables inheriting columns from parent tables.

Continued…

I recently came across an amazing feature in PostgreSQL: the RETURNING clause. This clause allows you to return specific data as the result of an INSERT or UPDATE query.

Often, after doing one of these queries, I’m interested in getting some data, such as an autogenerated primary key field, or maybe some defaulted data (like a created timestamp). Normally, one would have to do an additional query to get this data. Using RETURNING, we can do our data manipulation and retrieval in the same query.

Example:

-- Return just the ID:
 
INSERT INTO books(name, author) VALUES('Awesome Book', 'Smart Author') 
    RETURNING book_id;
 
-- Return more than one column:
 
INSERT INTO books(name, author) VALUES ('Sweet Book', 'Other Author') 
    RETURNING book_id, created_on;
 
-- Return all the columns:
 
INSERT INTO books(name, author) VALUES ('Silly Book', 'Airhead Author') 
    RETURNING *;

In our code, we can simply treat the return value of the INSERT or UPDATE code like we would a SELECT statement.

Some things to keep in mind, though:

1. If the UPDATE query affects multiple rows, multiple rows of data will be returned. If no rows are affected, none will be returned.
2. Normally the database would return the number of rows affected, but obviously we’re overriding the return value of the query. Obviously we can check the number of rows returned by the query (like we would with a SELECT) to get around this.