Arguile <arguile@lucentstudios.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
INSERTTO 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
