From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)atentus(dot)com> |
Cc: | Hannu Krosing <hannu(at)tm(dot)ee>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: DROP COLUMN misbehaviour with multiple inheritance |
Date: | 2002-09-13 03:40:21 |
Message-ID: | 14875.1031888421@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Alvaro Herrera <alvherre(at)atentus(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Philip Warner | 2002-09-13 03:42:23 | Re: OPAQUE and 7.2-7.3 upgrade |
Previous Message | Tom Lane | 2002-09-13 03:27:08 | Re: OPAQUE and 7.2-7.3 upgrade |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2002-09-13 04:56:19 | Re: DROP COLUMN misbehaviour with multiple inheritance |
Previous Message | Alvaro Herrera | 2002-09-13 02:52:40 | Re: DROP COLUMN misbehaviour with multiple inheritance |