Skip site navigation (1) Skip section navigation (2)

Re: DROP COLUMN misbehaviour with multiple inheritance

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)atentus(dot)com>
Cc: hannu(at)tm(dot)ee, pgsql-hackers(at)postgresql(dot)org
Subject: Re: DROP COLUMN misbehaviour with multiple inheritance
Date: 2002-09-29 02:00:49
Message-ID: 6853.1033264849@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
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

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2002-09-29 02:04:49
Subject: Re: 20020822_02_pitr.patch.gz
Previous:From: Tom LaneDate: 2002-09-29 01:47:59
Subject: Re: Improving backend startup interlock

pgsql-patches by date

Next:From: Bruce MomjianDate: 2002-09-29 02:04:49
Subject: Re: 20020822_02_pitr.patch.gz
Previous:From: Alvaro HerreraDate: 2002-09-29 00:26:55
Subject: CLUSTER ALL patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group