PG Bug reporting form <noreply@postgresql.org> writes:
> When dropping a column in a parent table, the change is propagated to child
> tables.
> But when a child has been moved out of the hierarchy and then back into
> it,
> this propagation appears to no longer work for that child table.
I believe this is operating as designed. When you dis-inherit the child
table, all its columns go to attinhcount = 0 and therefore get attislocal
set to true (since the alternative would be to drop them). Re-inheriting
increments attinhcount, but attislocal remains true. Then the DROP COLUMN
on the parent reduces attinhcount back to zero, but since attislocal is
still true, the column is not dropped.
One could argue that the re-inherit step ought to clear attislocal.
But I think that would just move the weird behaviors somewhere else,
primarily because there's no principled reason for ALTER ... INHERIT
to assume that the column never had a local definition.
In any case, this mechanism was intentionally designed to err on the
side of not throwing away data in questionable cases, and I think
that's a smart bias to have.
I believe there was a pretty thorough discussion of all this back when
we invented the attinhcount/attislocal tracking mechanism (before that,
there were some very unpleasant corner cases). You could try digging
in the archives if you want more detail.
regards, tom lane
