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