En Thu, 12 Sep 2002 23:40:21 -0400
Tom Lane <tgl@sss.pgh.pa.us> escribió:
> 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.
>
> We could probably cause gc1->name->attisinherited to be 2 in this
> scenario; does that help?
I'm trying to imagine a case where this is harmful, but cannot find any.
It would have to be proven that there is none; IMHO this is a little
deviating from the "reality".
> 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.
In the cases I've tried this works, and it seems to me that it is
correct; however, I haven't proven it is. Multiple inheritance and
multiple generations is weird.
It just ocurred to me that maybe I overlooked the
ALTER TABLE ONLY ... DROP COLUMN case, but I'm now going to bed. I'll
think about this case tomorrow.
> > 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?
Huh, I already did. Please think about my solution.
--
Alvaro Herrera (<alvherre[a]atentus.com>)
"Para tener mas hay que desear menos"
