Dear Michael,
This comes up often and the response is usually something like, "Rules are macros, which is why referring to NEW.id causes another evaluation of nextval(). If you don't want that to happen then use a trigger."
That is indeed what I gathered;-)
It might be sensible to avoid multiple evaluations for the new.* attributes when possible. I can foresee that it makes the implementation less straightforward wrt to a pure tree-rewriting stuff.
Also, there is no such thing as a SQL trigger, so one needs to install plpgsql to develop a simple trigger.
This comes up often enough that maybe it warrants a "Caveats with Rules" section in "The Rule System" chapter
There is neither such section nor subsection in chapter "the rule system". Maybe a sub-sub-section somewhere?
Table of Contents
32.1. The Query Tree
32.2. Views and the Rule System
32.2.1. How SELECT Rules Work
32.2.2. View Rules in Non-SELECT Statements
32.2.3. The Power of Views in PostgreSQL
32.2.4. Updating a View
32.3. Rules on INSERT, UPDATE, and DELETE
32.3.1. How Update Rules Work
32.3.2. Cooperation with Views
32.4. Rules and Privileges
32.5. Rules and Command Status
32.6. Rules versus Triggersand a link to that section in the CREATE RULE documentation, as well as mention in the FAQ.
I must admit that I did not look at the FAQ.
The general tone of the rule documentation is "look how great and powerful it is", and somehow it is nearly as great as promised, but nearly only.
Well, thanks for your comment,
-- Fabien.
---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
