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