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 e
Dear Tom,
This comes up often enough that maybe it warrants a "Caveats with
Rules" section in "The Rule System" chapter and a link to that section
in the CREATE RULE documentation, as well as mention in the FAQ.
Yeah. I have also thought about reorganizing the docs so that triggers
are presented
Michael Fuhr <[EMAIL PROTECTED]> writes:
> This comes up often enough that maybe it warrants a "Caveats with
> Rules" section in "The Rule System" chapter and a link to that
> section in the CREATE RULE documentation, as well as mention in the
> FAQ.
Yeah. I have also thought about reorganizing t
On Wed, Nov 10, 2004 at 10:23:41AM +0100, Fabien COELHO wrote:
> It seems that "on update do also" rules the new.* fields are evaluated
> several times instead of being computed once, which is a bad idea, esp.
> for "nextval".
This comes up often and the response is usually something like,
"Rul
I'd like to report the following "strange" behavior that I encountered
while trying (a bad idea, I know) to use a rule as a "poor man sql-trigger".
I noticed that I forget about the bug report guidelines...
The above mentionned strange behavior is with a recent cvs tree, between
beta3 and beta4,
Dear debuggers,
I'd like to report the following "strange" behavior that I encountered
while trying (a bad idea, I know) to use a rule as a "poor man sql-trigger".
It seems that "on update do also" rules the new.* fields are evaluated
several times instead of being computed once, which is a bad id
