pelago

The new year always brings with it a few small things that go bump in the morning. 2008 was no different. Intervals started behaving oddly on New Year’s Eve morning — the default timesheet was a year behind schedule. What happened?

In our PHP code, we are using the ISO-8601 week number of year, as specified on the PHP date function page, but we weren’t using ISO-8601 for the year. The ISO-8601 week number specifies the last monday of a year as the first week of the new year, if that new year begins before thursday. Intervals thought it was the first year of 2007!

In PHP, the fix was as easy as converting all instances of date(’Y') to date(’o'), according to php.net:

ISO-8601 year number. This has the same value as Y, except that if the ISO week number (W) belongs to the previous or next year, that year is used instead. (added in PHP 5.1.0)

That fixed everything on the PHP side of things. But next we had to dig into the SQL queries and get them to use the ISO Year.

Snag.

PostgreSQL 8.2.5 doesn’t support ISO Year in the Extract function. EXTRACT(ISOYEAR, timestamp) is being included in PostgreSQL 8.3, as specified here in the RC1 documentation. But PostgreSQL 8.3 hasn’t been released yet, and we needed to fix things immediately.

Our final PostgreSQL fix was to instead use the TO_CHAR(timestamp, ‘IYYY’) function. It’s not ideal to be using a string formatting function for data comparisons, because it slows down some of the queries. But we had to trade some performance to get things working properly again in the new year. As soon as the PostgreSQL developers release a stable version of 8.3, we’ll change our queries back to using EXTRACT(ISOYEAR, timestamp).

MySQL is great in that it really lets you get away with a lot. Something I’ve found frequently valuable is the ability to update a table in a particular order, such as when you want a column to have a particular numerical sequence, and you want that sequence to share the same order as another field. Let me give you an example.

In many of our tables we allow site administrators to sort elements (rows) according to a certain priority (in this case, 1 being the highest priority). For one particular client, they wanted the ability to sort their list of team members according to priority. This allowed them to order their employees according to any criteria they desire (say, in this case, seniority, or rank). However, recently they asked us to sort their employee table according to name. Under MySQL this would be easy. You could run the following:

SET @p=1;
UPDATE team SET priority = (@p:=@p+1) ORDER BY name ASC;


Piece of cake: each employee is given a certain priority according to name. However, under PostgreSQL, this is much more challenging, and I couldn’t find any easy solution on the web. It turns out, the solution requires the use of views, rules, and sequences, things that are foreign to most MySQL users and all but the more advanced PostgreSQL users. Here are the following steps:

1) You must first create a view on the table that you want to update in the particular order that you want to update by:

CREATE VIEW view_team AS SELECT * FROM team ORDER BY name ASC;


2) To run the update on the view you just created, you have to create a rule telling the view how to interpret UPDATE queries you’re going to run on it:

CREATE RULE rule_team AS ON UPDATE TO view_team DO INSTEAD UPDATE team SET priority = NEW.priority WHERE id = NEW.id;


This specifies that when you try to run an update on the view_team view, it will apply those changes to the team table where we want those changes to show up. You can change more than one field in this rule by adding more fields to the UPDATE part of that query, but since we are only applying changes to the priority field, this will suffice.

3) Create a sequence. This will update each row in sequence, and serves as an alternative to using user-defined variables, as we did in MySQL:

CREATE SEQUENCE team_priority_seq;


4) Update the view:

UPDATE view_team SET priority = nextval('team_priority_seq');


5) Now unless you want to keep the view, rule, and sequence around, you can drop them:

DROP SEQUENCE team_priority_seq;
DROP RULE rule_team ON view_team;
DROP VIEW view_team;


Hopefully if you followed those steps, your table should be sorted in exactly the order you want. Here is everything all at once:

CREATE VIEW view_team AS SELECT * FROM team ORDER BY name;
CREATE RULE rule_team AS ON UPDATE TO view_team DO INSTEAD
UPDATE team SET
priority = NEW.priority
WHERE id = NEW.id;
CREATE SEQUENCE team_priority_seq;
UPDATE view_team SET priority = nextval('team_priority_seq');
DROP SEQUENCE team_priority_seq;
DROP RULE rule_team ON view_team;
DROP VIEW view_team;


Cameron