Re: DROP COLUMN misbehaviour with multiple inheritance - Mailing list pgsql-hackers

From Tom Lane
Subject Re: DROP COLUMN misbehaviour with multiple inheritance
Date
Msg-id 12490.1032713783@sss.pgh.pa.us
Whole thread Raw
In response to Re: DROP COLUMN misbehaviour with multiple inheritance  (Alvaro Herrera <alvherre@atentus.com>)
Responses Re: DROP COLUMN misbehaviour with multiple inheritance  (Alvaro Herrera <alvherre@atentus.com>)
Re: DROP COLUMN misbehaviour with multiple inheritance  (Hannu Krosing <hannu@tm.ee>)
Re: DROP COLUMN misbehaviour with multiple inheritance  (Hannu Krosing <hannu@tm.ee>)
List pgsql-hackers
Alvaro Herrera <alvherre@atentus.com> writes:
>> Another interesting case is multiple inheritance.
>> 
>> create table p1 (f1 int);
>> create table p2 (f1 int);
>> create table c () inherits(p1, p2);
>> 
>> drop ONLY column p1.f1;
>> drop column p2.f1;
>> 
>> After this sequence, what is the state of c.f1?  Is it still there?
>> Should it be?

> Well, in this case the column is dropped.  If the last drop is ONLY, the
> column will stay (regardless of what the first drop did).

It seems to me that DROP ONLY should set attislocal true on each child
for which it decrements the inherit count, whether the count reaches
zero or not.  This would cause the behavior in the above case to be that
c.f1 stays around after the second drop (but can be dropped with a third
drop of c.f1 itself).  I think this is correct, since the implication of
DROP ONLY is that child columns are being cut loose from their parent's
apron strings and now have independent existence.

This is a minor tweak to your patch, and I'll make it work that way
unless I hear squawks...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Postmaster help output
Next
From: Tom Lane
Date:
Subject: Re: Schema vs Namespace