Re: DROP COLUMN misbehaviour with multiple inheritance

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)atentus(dot)com>
Cc: hannu(at)tm(dot)ee, pgsql-hackers(at)postgresql(dot)org
Subject: Re: DROP COLUMN misbehaviour with multiple inheritance
Date: 2002-09-22 16:56:23
Message-ID: 12490.1032713783@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Alvaro Herrera <alvherre(at)atentus(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-09-22 17:05:40 Re: Schema vs Namespace
Previous Message Alvaro Herrera 2002-09-22 15:57:49 Re: Postmaster help output

Browse pgsql-patches by date

  From Date Subject
Next Message Alvaro Herrera 2002-09-22 17:08:00 Re: DROP COLUMN misbehaviour with multiple inheritance
Previous Message Alvaro Herrera 2002-09-22 02:26:17 Re: DROP COLUMN misbehaviour with multiple inheritance