On Tue, Jun 2, 2015 at 10:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Keith Fiske <keith@omniti.com> writes:
> > On Tue, Jun 2, 2015 at 6:18 PM, Tom Lane <tgl@sss.pgh.pa.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
>
Agreed that if it's been there that long like that it would be hard to
change now. But it seems a thought for data safety (which I'm not against)
wasn't weighed carefully against how this behavior would appear to the
average user. If it can't be changed, I would definitely make note of that
in the Inheritance documentation somehow with a working example like you
gave. I hadn't even considered looking down in the notes in the ALTER TABLE
command for that. I just looked up in the DROP COLUMN section at the top.
Keith