Re: Dropping columns with inheritance not working as documented

Keith Fiske <keith(at)omniti(dot)com> writes:
> On Tue, Jun 2, 2015 at 6:18 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I think you might be misreading the docs. DROP COLUMN only propagates to
>> columns that have no independent reason to exist in the child.

> 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.

It is documented, for example in the ALTER TABLE reference page:

<para>
A recursive <literal>DROP COLUMN</literal> operation will remove a
descendant table's column only if the descendant does not inherit
that column from any other parents and never had an independent
definition of the column. A nonrecursive <literal>DROP
COLUMN</literal> (i.e., <command>ALTER TABLE ONLY ... DROP
COLUMN</command>) never removes any descendant columns, but
instead marks them as independently defined rather than inherited.
</para>

I'm not sure whether it's worth going into such details in section 5.9,
but certainly we could try to provide some explanation there, or wherever
it was that you were looking.

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

The killer argument, as I recall, was that we should take pains not
to irretrievably drop data if there was any doubt as to whether it
was still wanted. But even if you didn't believe that, there's now
a dozen years worth of backwards compatibility to worry about --- it's
been like this since 2002 or so.

regards, tom lane