On Monday, February 24, 2003, at 11:55 AM, Eric B.Ridge wrote:
> On Saturday, February 22, 2003, at 01:13 PM, Eric B.Ridge wrote:
>
>> On Friday, February 21, 2003, at 09:51 PM, Tom Lane wrote:
>>
>>> If you pull down the latest 7.3 branch version of spi.c
>>
>> Thanks again! I'll give it a shot on Monday.
>
> I just wanted to follow up and say that between this fix to spi.c,
> rewrite_invoke_max limit of 100, and the ALTER TABLE <view name> ALTER
> COLUMN foo SET DEFAULT feature, 7.3.2 is great. Thanks!
I hate to bring this subject up again, but I'm confused about when
default (view) values (via NEW) are evaluated when used in a
multi-statement insert rule.
xxx=# create table foo (id int8);
CREATE TABLE
xxx=# create sequence seq_foo_id;
CREATE SEQUENCE
xxx=# create view foo_view as select * from foo;
CREATE VIEW
xxx=# alter table foo_view alter column id set default
nextval('seq_foo_id');
ALTER TABLE
xxx=# create rule foo_insert_rule as on insert to foo_view do instead (
xxx(# insert into foo (id) values (NEW.id);
xxx(# insert into foo (id) values (NEW.id);
xxx(# );
CREATE RULE
xxx=# insert into foo_view default values;
INSERT 273920 1
xxx=# select * from foo;
id
----
1
2
(2 rows)
I would have expected "id" to be '1' in both rows. In fact, for what
I'm trying to do, it's a requirement.
Can anyone explain why NEW.id is being re-evaluated for each statement
in the rule? Is this by design?
eric
