Re: DROP COLUMN misbehaviour with multiple inheritance

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: DROP COLUMN misbehaviour with multiple inheritance
Дата
Msg-id 12490.1032713783@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: DROP COLUMN misbehaviour with multiple inheritance  (Alvaro Herrera <alvherre@atentus.com>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Postmaster help output
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Schema vs Namespace