Re: DROP COLUMN misbehaviour with multiple inheritance - Mailing list pgsql-hackers

On Sun, 2002-09-29 at 19:57, Tom Lane wrote:
> Hannu Krosing <hannu@tm.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