Re: Dropping columns with inheritance not working as documented

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Keith Fiske <keith(at)omniti(dot)com>
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-02 22:18:10
Message-ID: 7169.1433283490@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Keith Fiske <keith(at)omniti(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Keith Fiske 2015-06-03 01:43:46 Re: Dropping columns with inheritance not working as documented
Previous Message Keith Fiske 2015-06-02 21:52:05 Dropping columns with inheritance not working as documented