Re: Dropping columns with inheritance not working as documented

From: Keith Fiske <keith(at)omniti(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Dropping columns with inheritance not working as documented
Date: 2015-06-03 02:56:02
Message-ID: CAG1_KcAcrGUgPV_WLSuf2_d28nYUfGfm9vhVLzYO3pJjNk6xVQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Tue, Jun 2, 2015 at 10:24 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

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

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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Alvaro Herrera 2015-06-03 03:52:16 Re: Dropping columns with inheritance not working as documented
Previous Message Tom Lane 2015-06-03 02:24:48 Re: Dropping columns with inheritance not working as documented