Re: DROP COLUMN misbehaviour with multiple inheritance

Alvaro Herrera <alvherre(at)atentus(dot)com> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> escribi:
>> Actually, there might not be a problem. c1.name can't be deleted until
>> both p1.name and p2.name go away, and at that point we want both c1.name
>> and gc1.name to go away. So as long as we don't *recursively* decrement
>> the inherits count when c1.name.attisinherited hasn't reached 0, this
>> might be okay. But it needs thought.

> This is what I implemented on the patch I posted, I think. The idea is
> that attisinherited is decremented non-recursively, i.e. only in direct
> inheritors; and when it reaches zero the column is dropped, and its
> inheritors have it decremented also.

Yeah; after marginally more thought, I'm thinking that the correct
definition of attisinherited (need new name BTW) is "number of *direct*
ancestors this table inherits this column from". I think you are
describing the same idea.

Given the obvious algorithms for updating and using such a value,
does anyone see a flaw in the behavior?

One corner case is that I think we currently allow

create table p (f1 int);
create table c (f1 int) inherits(p);

which is useless in the given example but is not useless if c
provides a default or constraints for column f1. ISTM f1 should
not go away in c if we drop it in p, in this case. Maybe we want
not an "inherits count" but a "total sources of definitions count",
which would include 1 for each ancestral table plus 1 if declared
locally. When it drops to 0, okay to delete the column.

> however, I haven't proven it is. Multiple inheritance and
> multiple generations is weird.

What he said... I'm way too tired to think this through tonight...

regards, tom lane