Re: DROP COLUMN misbehaviour with multiple inheritance

Tom Lane dijo:

> Hannu Krosing <hannu(at)tm(dot)ee> writes:
>
> > The count approach seems definitely the right way, but a check (possibly
> > a slow one) can be probably done without initdb.
>
> Slow, complicated to code, and deadlock-prone (since you'd have to
> acquire locks on the other parent tables). My feeling is we fix this
> with a counted attisinherited field, or don't fix at all.

All right, I now have all the catalog changes on place; this is the easy
part (is an int2 count enough?).

But when actually dropping a column, the recursion cannot be done the
way it's done now, fetching the whole inheritor tree in one pass,
because there's no way to distinguish the direct ones that have the
attisinherited count greater than 1 from deeper ones; it has to be done
step by step. If this is not clear, imagine the following situation:

create table p1(id int, name text);
create table p2(id2 int, name text);
create table c1(age int) inherits(p1,p2);
create table gc1() inherits (c1);

p1 and p2 have name->attisinherited=0, while c1 has
name->attisinherited=2. But gc1->name->attisinherited=1. If I just
recurse the tree the way it's done now, I will happily drop "name" from
gc1 while keeping it on c1. So I have to switch from
find_all_inheritors() to find_inheritance_children() and keep recursing
until there are no more inheritors (I still have to check if there are
other gotchas with this approach, or optimizations to be done). I am
already midway with this, but wanted to let you know in case the patch
is rejected.

Is this Ok? I see this is getting away from the "trivial fix" camp.

--
Alvaro Herrera (<alvherre[a]atentus.com>)
"The Gord often wonders why people threaten never to come back after they've
been told never to return" (www.actsofgord.com)