Tom Lane wrote:
Jeff Boes <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
No kidding. A rule is a macro and therefore has the usual risks of
multiple evaluations of arguments.
But shouldn't "new.job_id" use the value that was already recorded in
the original row?
There is no "v
Jeff Boes <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> No kidding. A rule is a macro and therefore has the usual risks of
>> multiple evaluations of arguments.
> But shouldn't "new.job_id" use the value that was already recorded in
> the original row?
There is no "value that was already rec
Tom Lane wrote:
Jeff Boes <[EMAIL PROTECTED]> writes:
It appears that the rule is inserting the row copies into
job_queue_trace with a job_id value that is one higher than the job_id
from the original row. Almost as though it was re-evaluating the
sequence ...
No kidding. A rule is a ma
Jeff Boes <[EMAIL PROTECTED]> writes:
> It appears that the rule is inserting the row copies into
> job_queue_trace with a job_id value that is one higher than the job_id
> from the original row. Almost as though it was re-evaluating the
> sequence ...
No kidding. A rule is a macro and therefo
(I thought I posted this yesterday from Google Groups, but it doesn't
appear to have "taken".)
I'm having a problem with a rule designed to log new rows inserted into
one table. The base table is very volatile; rows are inserted from
various places, including both application code and triggers.
