Re: DROP COLUMN misbehaviour with multiple inheritance

En Thu, 19 Sep 2002 14:06:05 -0400
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> escribió:

> Alvaro Herrera <alvherre(at)atentus(dot)com> writes:
> > Tom Lane dijo:
> >> One corner case is that I think we currently allow
> >>
> >> create table p (f1 int);
> >> create table c (f1 int) inherits(p);
>
> > In this case, c.f1.attisinherited count is 2; thus when I drop f1 from
> > p, it is not dropped from c.
>
> That seems right, but the problem I have with it is that the resulting
> state of c.f1 is attisinherited = 1. This means that you cannot drop
> c.f1. It seems to me that we should have this behavior:

New patch attached. This one should answer your concerns. This is the
idea implemented:

> We might need two fields :-( ... a "locally defined" boolean and a
> "number of times inherited" counter.

Some discussion:

> create table p (f1 int);
> create table c (f1 int not null) inherits(p);
>
> drop column p.f1;
> -- c.f1 GOES AWAY, because its inherit count went to zero

In this case, the attached code preserves f1. It's not clear whether
the user wants the column to stay or not, but if he is defining it
twice, let him drop it twice if he wants it to go away.

> Another interesting case is multiple inheritance.
>
> create table p1 (f1 int);
> create table p2 (f1 int);
> create table c () inherits(p1, p2);
>
> drop ONLY column p1.f1;
> drop column p2.f1;
>
> After this sequence, what is the state of c.f1? Is it still there?
> Should it be? If it is still there, will it be possible to get rid of
> it with "drop column c.f1"? What if we did DROP ONLY on *both*
> ancestors?

Well, in this case the column is dropped. If the last drop is ONLY, the
column will stay (regardless of what the first drop did). This one
seems very tricky and I don't see a way to do otherwise.

Other cases (such as the set of four you posted) are handled in the
"natural" way you described. Regression tests for all those four are
included, along another case that was the start of all this.

Please review the patch. It should be current as of your commit of
20:30 today, but I'm not sure (anoncvs delays and all -- there are
changes to the same files).

--
Alvaro Herrera (<alvherre[a]atentus.com>)
"Hay dos momentos en la vida de un hombre en los que no debería
especular: cuando puede permitírselo y cuando no puede" (Mark Twain)