Re: DROP COLUMN misbehaviour with multiple inheritance

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. (Yes, I
know that the code takes that combination right now, but erroring out
instead is on the "must fix before release" list. Ditto for RENAME
ONLY.)

> 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.

>> 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.

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. 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. IMHO this is a good example of why attislocal is
useful.

regards, tom lane