Re: DROP COLUMN misbehaviour with multiple inheritance

On Wed, 2002-09-25 at 04:33, Alvaro Herrera wrote:
> Hannu Krosing dijo:
>
> > On Wed, 2002-09-25 at 04:13, Tom Lane wrote:
> > > Hannu Krosing <hannu(at)tm(dot)ee> writes:
> > > > 1) --------------------------------
> > > > create table p1 (f1 int, g1 int);
> > > > create table p2 (f1 int, h1 int);
> > > > create table c () inherits(p1, p2);
> > > > drop column p2.f1; -- this DROP is in fact implicitly ONLY
> > >
> > > Surely not? At least, I don't see why it should be thought of that way.
> > > There's always a difference between DROP and DROP ONLY.
> >
> > What will be the difference in the user-visible schema ?
>
> If I understand the issue correctly, this is the key point to this
> discussion. The user will not see a difference in schemas, no matter
> which way you look at it. But to the system catalogs there are two ways
> of representing this situation: f1 being defined locally by c (and also
> inherited from p1) or not (and only inherited from p1).

Ok, I think I'm beginning to see Tom's point.

So what Tom wants is that doing DROP ONLY will push the definition down
the hierarchy on first possibility only as a last resort.

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.

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 ?

what would drop column p.f1; have done - would it have left c.f1 intact?

> I think the difference is purely phylosophical, and there are no
> arguments that can convince either party that it is wrong.

There seem to be actually 3 different possible behaviours for DROP
COLUMN for hierarchies.

1. DROP ONLY - the weakest - drops the column and moves the "original"
(or explicit, defined-here) definition down to all children if not
already found there too.

2. DROP - midlevel - drops the column and its inherited definitions in
children but stops at first foreign definition (defined locally or
inherited from other parents).

3. DROP FORCE - strongest ( more or less what current drop seems to do.)
- walks down the hierarchy and removes all definitions, weather
inherited or local, only leaves definitions inherited from other
parents. Perhaps it should just fail in case of multiply inherited field
?

Maybe it was too early to put the DROP ONLY functionality in ?

> Anyway, there's always a set of commands that can make the user go from
> one representation to the other. He just has to be careful and know
> exactly which way the system will work. Whichever way it works, it
> should be clearly and carefully documented in the ALTER TABLE reference.

Amen.

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