Re: DROP COLUMN misbehaviour with multiple inheritance

On Mon, 2002-09-30 at 00:05, Alvaro Herrera wrote:
> On 29 Sep 2002, Hannu Krosing wrote:
>
> > On Sun, 2002-09-29 at 19:57, Tom Lane wrote:
> > > Hannu Krosing <hannu(at)tm(dot)ee> writes:
> > > > I'd propose that ADD ONLY would pull topmost attislocal up (reset it
> > > > from the (grand)child) whereas plain ADD would leave attislocal alone.
> > >
> > > ADD ONLY? There is no such animal as ADD ONLY, and cannot be because
> > > it implies making a parent inconsistent with its children.
> >
> > I meant ADD ONLY to be the exact opposite of DROP ONLY - it adds parent
> > column and removes attislocal from children. Simple ADD would _not_
> > remove attislocal from children with matching column.
>
> Consistency requires that it be exactly the opposite.

Consistency seems to mean different things to different people - an a
"natural" meaning is often hard to see in a non-natural language (SQL).
So is it "ADD ONLY to table" or "ADD the ONLY definition" or "ADD ONLY
don't reset attislocal" or "ADD ONLY as opposite of DROP ONLY")

But I'd be happy with any meaning, as long as the functionality is there
and it is clearly documented.

Your definition of "ADD to this table ONLY and leave other definitions
alone" is easy to accept.

> When you ADD
> ONLY, you want only in the "local" table, so children still have a local
> definition; OTOH, when you ADD (recursively) you want all children to
> get non-local status.

Perhaps ADD should either have ONLY or ALL and function without either
only when there is no matching column in any of the child tables.

> Suppose
> CREATE TABLE p (f1 int);
> CREATE TABLE c (f2 int) INHERITS (p);
> c.f2.attislocal = true
>
> Now,
> ALTER TABLE ONLY p ADD COLUMN f2 int
> should leavy c.f2.attislocal alone, while
> ALTER TABLE p ADD COLUMN f2 int
> should reset it.
>
> This is the opposite of your proposal, and I don't think it exists in
> Tom's proposal.

I also like the ablility to undo accidental DROP ONLY, which is missing
in Toms proposal.

> I think this is also consistent with the fact that ONLY requires the
> column to exist in all children, while non-ONLY creates it where it
> doesn't exist, and merges (resetting attislocal if set -- it could be
> inherited from some other parent) where it exists.

For completeness there should be a third behaviour that would work like
ONLY for existing columns in children, but add it to children where it
is missing.

This would be needed to effectively undo a DROP COLUMN where it was
multiply inherited and/or locally defined in some children.

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