OSNews

One of my favorite features of PostgreSQL is the RULE system, which I think takes a little explaining for those not familiar. Think of it this way:

The rule system is to SQL queries as Apache's mod_rewrite is to HTTP requests.

This means that for any table or view in your system, you can make your query do other (or additional) stuff internally.

For example, every time someone does SELECT * FROM accounts, you might want to log that activity, so you define a rule that also does "INSERT into logtable VALUES(CURRENT_USER, CURRENT_DATE, 'user selected from accounts');". This happens without affecting the user query in any way.

Or, for example, upon delete in a certain table, you could use a rule to insert the deleted row into a backup table. Rules can be used to make a view updateable in _any_ way you might want, including any number of base tables.

Now, you might argue "this is just a trigger in disguise". There is a lot of overlap between what a trigger can handle and what a rule can handle, although AFAIK only a couple DBMSs allow you to create an ON SELECT trigger. The thing is, it is conceptually more elegant and simple to use rules, while triggers+procedures allow you to execute more arbitrarily complex operations. So I would argue that RULES are a better solution to many of the "business rules" that you would want to implement, while triggers and procedures can be used to handle things that are difficult with regular SQL.

So this leaves me with a question for the PostgreSQL team: in general, do rules take up less resources than triggers? As I understand it, rules make up a large part of PostgreSQL internal logic anyway, so it would seem to make sense that extensive use of rules might perform better than extensive use of triggers and procedures. Any comments, guys?