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

[ back to thinking about this patch ]

Alvaro Herrera <alvherre@atentus.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:

create table p (f1 int);
create table c (f1 int not null) inherits(p);

drop column c.f1;
-- should be rejected since c.f1 is inherited
drop column p.f1;
-- c.f1 is still there, but no longer inherited
drop column c.f1;
-- should succeed; but will fail with patch as given

as compared to

create table p (f1 int);
create table c () inherits(p);

drop column c.f1;
-- should be rejected since c.f1 is inherited
drop column p.f1;
-- c.f1 is dropped now, since there is no local definition for it

And if you aren't confused yet, what about non-recursive drops of p.f1
(ie, alter table ONLY p drop column f1)?  This case seems clear:

create table p (f1 int);
create table c () inherits(p);

drop column c.f1;
-- should be rejected since c.f1 is inherited
drop ONLY column p.f1;
-- c.f1 is NOT dropped, but must now be considered non-inherited
drop column c.f1;
-- should succeed

And then I think we should say

create table p (f1 int);
create table c (f1 int not null) inherits(p);

drop column c.f1;
-- should be rejected since c.f1 is inherited
drop ONLY column p.f1;
-- c.f1 is still there, but no longer inherited
drop column c.f1;
-- should succeed

I am not sure how to make all four of these cases work.  We might need
two fields :-( ... a "locally defined" boolean and a "number of times
inherited" counter.  This seems like overkill though.

If we don't have the "locally defined" boolean then I think we have to
make the first case work like so:

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

Is this reasonable behavior?  I'm not sure.  You could probably argue
it either way.

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?
        regards, tom lane