Re: RULE vs. SEQUENCE - Mailing list pgsql-hackers

From Karel Zak
Subject Re: RULE vs. SEQUENCE
Date
Msg-id Pine.LNX.3.96.1000904130315.219E-100000@ara.zf.jcu.cz
Whole thread Raw
In response to Re: RULE vs. SEQUENCE  (Jan Wieck <janwieck@Yahoo.com>)
Responses Re: RULE vs. SEQUENCE
List pgsql-hackers
On Mon, 4 Sep 2000, Jan Wieck wrote:

> >  I have a question... why RULE call nexval() and data in RULE statement are
> > differend than data in original stmt.
> 
>     It's  a known "feature", and I don't know any way of changing
>     it.
IMHO docs is quiet about it... 

>     The problem is, that NEW.attname in a rule  means,  "whatever
>     is  in  the targetlist of the INSERT when applying the rule".
>     In your example, it'll be  a  call  to  nextval().  The  rule
>     system  doesn't  know  that  this targetlist expression has a
>     side-effect (incrementing the sequence).
But, why 'NEW' tuple is in the rewriter created again, why is not used 
original tuple from original statement ... like in triggers? 
Ooops yes, rewriter is before executor...hmm...

>     Thus, the rule creates a second query  which  does  it's  own
>     calls to nextval() when executed.
But executor can knows that somethig was already executed, we can mark 
some already executed expressions in rewriter and not execute it again in 
final executor... like:

typedef  some_expr {bool    executed;Datum    *result;....
} some_expr;

IMHO this is a good point for 7.2 ...

                    Karel



pgsql-hackers by date:

Previous
From: Jan Wieck
Date:
Subject: Re: RULE vs. SEQUENCE
Next
From: t-ishii@sra.co.jp
Date:
Subject: Re: Re: [PATCHES] Important 7.0.* fix to ensure buffers are released