On Thu, Mar 31, 2011 at 6:06 AM, Noah Misch <n...@leadboat.com> wrote: >> I think this is a manifestation the same problem mentioned here: >> >> http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=31b6fc06d83c6de3644c8f2921eb7de0eb92fac3 >> >> I believe this requires some refactoring to fix. It would be good to do >> that. > > 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?
I had exactly what you just said 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? Not sure. I think that anything we do here is bound to have some corner cases that are not quite right for so long as NOT NULL constraints aren't represented in pg_constraint, and it's way too late to dredge up that issue again for 9.1. I'm somewhat inclined to just defer fixing it until we get that work committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
