Re: DROP COLUMN misbehaviour with multiple inheritance - Mailing list pgsql-hackers

From Tom Lane
Subject Re: DROP COLUMN misbehaviour with multiple inheritance
Date
Msg-id 14875.1031888421@sss.pgh.pa.us
Whole thread Raw
In response to Re: DROP COLUMN misbehaviour with multiple inheritance  (Alvaro Herrera <alvherre@atentus.com>)
Responses Re: DROP COLUMN misbehaviour with multiple inheritance  (Alvaro Herrera <alvherre@atentus.com>)
List pgsql-hackers
Alvaro Herrera <alvherre@atentus.com> writes:
> 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.

Ick.  I hadn't thought that far ahead.

We could probably cause gc1->name->attisinherited to be 2 in this
scenario; does that help?

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.

> I see this is getting away from the "trivial fix" camp.

Yup.  Let's step back and think carefully before we plunge into the
coding.  What goes away when, and how do we define the inherits-count
to make it work right?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: OPAQUE and 7.2-7.3 upgrade
Next
From: Philip Warner
Date:
Subject: Re: OPAQUE and 7.2-7.3 upgrade