Re: DROP COLUMN misbehaviour with multiple inheritance

Tom Lane kirjutas P, 22.09.2002 kell 18:56:
> 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 not be what I e'd expect - if c inherited f1 twice and then
one of the parents disinherits it, then it would still be inherited from
the other parent

> 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'd vote for the way Alvaro describes it - keep the attislocal=false
while there exist parents from which the column was inherited.

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

For me the implication is that ONLY this parent cuts loose the strings
from its side, but should not mess with anything the child inherits from
other parties.

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

I was disconnected for the weekend, I hope this is not too late to
squawk ;)

-----------------
Hannu