The restriction is not that: the restriction is that you can't have an infinite recursion in your rules. The above is infinitely recursive because it says that for any UPDATE on mytable, you should also do an UPDATE on mytable ... but then for that UPDATE you also need to do another UPDATE on mytable ... etc. The bodies of rules are not exempt from rule expansion.
Understood. Even after 12 hours of sleep (I love Saturdays!), I still can't see how an update rule wouldn't cause infinite recursion if it tried to update its target.
It might be interesting to change that definition, so that a rule like
the above could be written that wouldn't recursively trigger itself.
This would need a lot of careful thought though. In most cases you *do*
want rule bodies to be rule-expanded.
I sure want rule bodies to be rule-expaned! Rule's are super cool and extremely flexible as they are.
A different tack that might be interesting to think about is to invent a notion of an "update default" for a column, analogous to the existing "insert default". The normal behavior is that the "update default" is the old value, but if you could specify some computable expression to use instead, this and related problems could be solved with a much simpler mechanism than a rule.
This thought ran through my head last night. Something like:
CREATE TABLE foo (
id int4 DEFAULT nextval('foo_seq'),
d timestamp DEFAULT now() ON UPDATE now()
);But it seems that if the user explicitly provided a value for 'd', you'd want to use that over the computed value.
Whatever the details, it would be a very useful feature to have.
eric
---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
