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: | Postg토토 사이트SQL : Postg토토 사이트SQL 메일 링리스트 : 2015-06-03 이후 PGSQL-BUGS 02:56 |
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
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 |