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
Re: DROP COLUMN misbehaviour with multiple inheritance Re: DROP COLUMN misbehaviour with multiple inheritance |
Список | 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 по дате отправления: