--On 31. März 2011 06:06:49 -0400 Noah Misch <n...@leadboat.com> wrote:
The best way I can see is to make ATExecAddColumn more like ATExecDropColumn,
ATAddCheckConstraint, and ATExecDropConstraint. Namely, recurse at Exec-time
rather than Prep-time, and cease recursing when we satisfy the ADD COLUMN
with a merge. Did you have something else in mind?
Incidentally, when we satisfy an ADD COLUMN with a merge, we do not check or
update attnotnull:
create table parent();
create table child(c1 text) inherits (parent);
alter table parent add column c1 text not null;
\d child
We could either update attnotnull (and schedule a phase-3 scan of the table)
or throw an error. For ALTER TABLE ... INHERIT, we throw the error. For
CREATE TABLE ... INHERITS, we add the NOT NULL (and no scan is needed). I'd
weakly lean toward throwing the error. Opinions?
Hmm this looks like the same kind of problem i'm currently faced with when
working on tracking inheritance counters for NOT NULL constraint at the moment
(see
<http://git.postgresql.org/gitweb?p=users/bernd/postgres.git;a=shortlog;h=refs/heads/notnull_constraint>
for a heavy WIP patch). It currently recurses and seems to do the right thing
(tm) for your example above, but i'm far from being certain that the way i'm
undertaking here is correct. It indeed discovered a bug i had in my recursion
code...
--
Thanks
Bernd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
