Re: DROP COLUMN misbehaviour with multiple inheritance

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.

> > The use of ONLY with this meaning is for the symmetry with DROP ONLY.
>
> But it's not a symmetrical situation. The children must contain every
> column in the parent; the reverse is not true. Some asymmetry in the
> commands is therefore unavoidable.

Perhaps some mirror command then: DROP ONLY <--> ADD ALL ?

> >> I would find it quite surprising if I could destroy c.f2 by adding
> >> and then dropping p.f2.
>
> > This should depend on weather you drop ONLY
>
> I disagree. Your analogy to a CASCADE foreign key is bad, because
> the foreign key constraint is attached to the column that might lose
> data. Thus you (presumably) know when you create the constraint what
> you are risking. Losing existing child data because of manipulations
> done only on the parent --- perhaps not even remembering that there
> is a conflicting child column --- strikes me as dangerous. It seems
> like an indirect, "action at a distance" behavior.

What about warning the user and making him use FORCE in ambiguous cases
(like when some children don't have that column) ?

> Here is another scenario: suppose p has many children, but only c42
> has a column f2. If I "alter table p add column f2", now p and
> all the c's will have f2. Suppose I realize that was a mistake.
> Can I undo it with "alter table p drop column f2"? Yes, under my
> proposal; no, under yours.

"YES" under mine, unless you did "alter table ONLY p add column f2" ,
which would have removed the local definition from children.

> In yours, the only way would be to
> do a DROP ONLY on p and then retail DROPs on each of the other
> children. This would be tedious and error-prone. If some random
> subset of the children had f2, it'd be even worse --- it would
> be difficult even to identify which children had f2 before the
> ADD operation.

Your proposal and mine are the same in case ONLY is not given. The
option ADD ONLY is proposed just to make it easy to undo a DROP ONLY.

Under your proposal I see no easy way to undo DROP ONLY (for example to
do DROP instead).

> IMHO this is a good example of why attislocal is useful.

I don't doubt usefulness of attislocal, I just want to make sure it is
used in a consistent manner.

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