Re: Dropping columns with inheritance not working as documented

On Tue, Jun 2, 2015 at 6:18 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Keith Fiske <keith@omniti.com> writes:
> > According to the documentation, dropping a column should be propagated
> down
> > to all children. This only seems to happen for columns that are added
> AFTER
> > a child table is inherited. There's no way to tell when a column was
> added
> > to an inheritance set, so this could be very confusing for someone down
> the
> > line that wasn't there when a table was set up.
>
> I think you might be misreading the docs.  DROP COLUMN only propagates to
> columns that have no independent reason to exist in the child.  For
> instance, given
>
>         create table p (f1 int);
>
> these two commands have different results:
>
>         create table c () inherits (p);
>
>         create table c (f1 int) inherits (p);
>
> In the second case, c.f1 has two reasons to exist: it was declared locally
> to c, and it was inherited from p.  Dropping p's f1 would remove only one
> of those reasons to exist, so c.f1 would still be there.
>
> If you do something like
>
>         create table c (f1 int);
>         alter table c inherit p;
>
> that's treated as the second case.  This is a debatable call but that's
> the way we decided it should work back when these commands were
> implemented.
>
> FYI, the pg_attribute columns attislocal and attinhcount track the state
> necessary to implement this behavior.
>
>                         regards, tom lane
>

Honestly, this is incredibly unclear in the documentation. I have no idea
how to even edit the documentation to explain that clearly to someone
coming into this. Just doing the scenario I laid out in my example makes it
clear that this is really not intuitive at all. You can see the same
confusion from the person that reported it in the pg_partman ticket.

Just imagine you're someone that inherited (great choice of words) some
long running system and you decide to drop some columns from a parent table
that are no longer needed. Some where there when inheritance was set up,
some were added later. Without deep internals knowledge, you'd have no idea
which ones are  which. All you'd see is some column drops propagating down
and others not.

Any chance on some documentation clarity? Or honestly, some further
justification for why it needs to stay like this?

--
Keith Fiske
Database Administrator
OmniTI Computer Consulting, Inc.
http://www.keithf4.com