Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
