Re: RULE vs. SEQUENCE

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

In response to

Responses

Browse pgsql-hackers by date

  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