Re: BUG #5856: pg_attribute.attinhcount is not correct.

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