Re: DROP COLUMN misbehaviour with multiple inheritance

Alvaro Herrera <alvherre(at)atentus(dot)com> writes:
> I have this almost ready. The thing I don't have quite clear yet is
> what to do with attislocal. IMHO it should not be touched in any case,
> but Hannu thinks that for symmetry it should be reset in some cases.

My feeling would be to leave it alone in all cases. If I have

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

I would find it quite surprising if I could destroy c.f2 by adding
and then dropping p.f2.

> Also, what do you mean by conflicts on defaults? I don't think the
> parent should take into consideration what the defaults are for its
> children. Same for constraints.

Well, the rules will probably have to be different for this case than
they are when creating a child below an existing parent. In particular,
if the ADD COLUMN operation is trying to create constraints (including
a simple NOT NULL), I'm inclined to fail rather than merge if the
existing child column does not already have matching constraints.
It would seem surprising to me that creating a parent column in this
way could allow the formerly free-standing child column to suddenly
have constraints it didn't have before. Also, you'd have to scan the
child rows to see whether they all meet the constraint, which would
be slow. For example, if you wanted to do

alter table p add column f2 text not null;

in the above example, I think it is reasonable to insist that you first
do

alter table c alter column f2 set not null;

to make it perfectly clear all 'round that you are accepting an
alteration in the existing column.

regards, tom lane