On Jan 24, 2004, at 2:34 PM, Tom Lane wrote:
> 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
