From: | Karel Zak <zakkr(at)zf(dot)jcu(dot)cz> |
---|---|
To: | Jan Wieck <janwieck(at)Yahoo(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: RULE vs. SEQUENCE |
Date: | 2000-09-04 11:16:45 |
Message-ID: | Pine.LNX.3.96.1000904130315.219E-100000@ara.zf.jcu.cz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | t-ishii | 2000-09-04 11:29:36 | Re: Re: [PATCHES] Important 7.0.* fix to ensure buffers are released |
Previous Message | Hannu Krosing | 2000-09-04 11:01:14 | Re: RULE vs. SEQUENCE |