Re: DROP COLUMN misbehaviour with multiple inheritance

Alvaro Herrera kirjutas K, 25.09.2002 kell 02:45:
> Hannu Krosing dijo:
>
> > For me it feels assymmetric (unless we will make attislocal also int
> > instead of boolean ;). This assymetric nature will manifest itself when
> > we will have ADD COLUMN which can put back the DROP ONLY COLUMN and it
> > has to determine weather to remove the COLUMN definition from the child.
>
> Well, the ADD COLUMN thing is something I haven't think about. Let's
> see: if I have a child with a local definition of the column I'm adding,
> I have to add one to its inhcount, that's clear. But do I have to reset
> its attislocal?

I'd guess that it should reset attislocal if ONLY is specified (to be
symmetric with behaviour of drop ONLY).

> > What does the current model do in the following case:
> >
> > create table p (f1 int, g1 int);
> > create table c (f1 int) inherits(p);
> > drop column c.f1;
> >
> > Will it just set attisinh = 1 on c.f1 ?
>
> No, it will forbid you to drop the column. That was the intention on
> the first place: if a column is inherited, you shouldn't be allowed to
> drop or rename it. You can only do so at the top of the inheritance
> tree, either recursively or non-recursively. And when you do it
> non-recursively, the first level is marked non-inherited.

And my views differed from Tom's on weather to do it always or only when
the column was dropped the last parent providing it for inheritance.

Lets hope that possible move from INHERITS to (LIKE,...)UNDER will make
these issues clearer and thus easier to discuss and agree upon.

> > There seem to be actually 3 different possible behaviours for DROP
> > COLUMN for hierarchies.
>
> Well, I'm not too eager to discuss this kind of thing: it's possible
> that multiple inheritance goes away in a future release, and all these
> issues will possibly vanish. But I'm not sure I understand the
> implications of "interfaces" (a la Java multiple inheritance).

I don't think that issues for inheriting multiple columns will vanish
even for SQL99 way of doing nheritance (LIKE/UNDER), as there can be
multiple LIKE's and afaik they too should track changes in parent
columns.

But I don't think that it is very important to reach concensus for 7.3
as the whole inheritance area in postgres will likely be changed.

I think these will be items for discussion once 7.4 cycle starts.

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