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.

Would it then not produce a situation, which can't be reproduced using
just CREATEs ? i.e. same column in bot parent (p2.f1) and child (c.f1)
but _not_ inherited ??

Then there would be no way to move a field from one parent table to
another and still have it as an inherited column in child.

It also seems bogus considering when doing SELECT * FROM p2 -- How
should the select behave regarding c.f1 - there is a field with the same
name and type but not inherited .

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

What if you have a deeper hierarchy under c - will this make you
traverse them all to drop f1 ?

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

From (this) parent's but not from (other) parents' ;)

Like In real world one should only be allowed to disinherit what _he_
owns.

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