On Thu, Mar 31, 2011 at 6:06 AM, Noah Misch <noah@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
