From: | Jan Wieck <janwieck(at)Yahoo(dot)com> |
---|---|
To: | Karel Zak <zakkr(at)zf(dot)jcu(dot)cz> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: RULE vs. SEQUENCE |
Date: | 2000-09-04 12:02:46 |
Message-ID: | 200009041202.HAA02041@jupiter.jw.home |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Karel Zak wrote:
>
>
> Hi,
>
> 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.
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).
Thus, the rule creates a second query which does it's own
calls to nextval() when executed.
> It's interesting feature (6.5, 7.0, 7.1...). How is a possible in RULE
> obtain same data as in 'aa' table for a default data from the sequence.
The query rewrite rule system behaves like this since 4.2 (or
even earlier). Since 6.4 it does the right things on UPDATE
and DELETE too. Don't know when we introduced sequences or
better "functions that have such nasty side-effects".
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #
From | Date | Subject | |
---|---|---|---|
Next Message | Karel Zak | 2000-09-04 12:05:05 | Re: RULE vs. SEQUENCE |
Previous Message | t-ishii | 2000-09-04 11:29:36 | Re: Re: [PATCHES] Important 7.0.* fix to ensure buffers are released |