Skip site navigation (1) Skip section navigation (2)

Re: New default ignored by pre-exising insert rulesets.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Arguile <arguile(at)lucentstudios(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: New default ignored by pre-exising insert rulesets.
Date: 2001-10-24 22:41:38
Message-ID: 25539.1003963298@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackers
Arguile <arguile(at)lucentstudios(dot)com> writes:
>   If a table field is altered to add a default, the default value is
> bypassed by pre-existing rules.

Yeah, this problem has been known for awhile (to me at least).  The
difficulty is that default values are added to INSERTs by the parser,
which is before rule creation and expansion.  So the saved info about
the rule already has all the defaults it's gonna get.  What's worse,
it won't track changes in existing defaults (though I'm not sure we
support altering defaults, anyway).  If I do

regression=# create table foo (f1 int default 1, f2 int default 2);
CREATE
regression=# create view v1 as select * from foo;
CREATE
regression=# create rule v1i as on insert to v1 do instead
regression-# insert into foo values(new.f1);
CREATE
regression=# select pg_get_ruledef('v1i');
                                       pg_get_ruledef

--------------------------------------------------------------------------------------------
 CREATE RULE v1i AS ON INSERT TO v1 DO INSTEAD INSERT INTO foo (f1, f2) VALUES (new.f1, 2);
(1 row)

then I can see that the defaults have crept into what's stored for the
rule.

I believe the best fix for this is to move default-insertion out of the
parser and do it during planning, instead --- probably at the same
place that manipulates the insert's targetlist to match the column
ordering of the table.  A possible objection is that default expressions
wouldn't be subject to rule manipulation, but we don't have any feature
that requires that anyway.

Comments anyone?

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2001-10-24 23:06:22
Subject: Re: Proposed new create command, CREATE OPERATOR CLASS
Previous:From: Ross J. ReedstromDate: 2001-10-24 22:27:35
Subject: Re: schema support, was Package support for Postgres

pgsql-bugs by date

Next:From: pgsql-bugsDate: 2001-10-24 23:14:37
Subject: Bug #491: ERROR: RelationClearRelation: relation using JDBC
Previous:From: Tom LaneDate: 2001-10-24 19:51:24
Subject: Re: Decimal digits in timeofday()

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group