Re: [BUGS] New default ignored by pre-exising insert rulesets.
От | Tom Lane |
---|---|
Тема | Re: [BUGS] New default ignored by pre-exising insert rulesets. |
Дата | |
Msg-id | 25539.1003963298@sss.pgh.pa.us обсуждение исходный текст |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: