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

--On 31. März 2011 06:06:49 -0400 Noah Misch <noah(at)leadboat(dot)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