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

From Alvaro Herrera
Subject Re: DROP COLUMN misbehaviour with multiple inheritance
Date
Msg-id Pine.LNX.4.44.0209241925130.3583-100000@David
Whole thread Raw
In response to Re: DROP COLUMN misbehaviour with multiple inheritance  (Hannu Krosing <hannu@tm.ee>)
Responses Re: DROP COLUMN misbehaviour with multiple inheritance
List pgsql-hackers
Hannu Krosing dijo: 

> On Wed, 2002-09-25 at 04:13, Tom Lane wrote:
> > Hannu Krosing <hannu@tm.ee> writes:
> > > 1) --------------------------------
> > > create table p1 (f1 int, g1 int);
> > > create table p2 (f1 int, h1 int);
> > > create table c () inherits(p1, p2);
> > > drop column p2.f1; -- this DROP is in fact implicitly ONLY
> > 
> > Surely not?  At least, I don't see why it should be thought of that way.
> > There's always a difference between DROP and DROP ONLY.
> 
> What will be the difference in the user-visible schema ?

If I understand the issue correctly, this is the key point to this
discussion.  The user will not see a difference in schemas, no matter
which way you look at it.  But to the system catalogs there are two ways
of representing this situation: f1 being defined locally by c (and also
inherited from p1) or not (and only inherited from p1).

I think the difference is purely phylosophical, and there are no
arguments that can convince either party that it is wrong.

Anyway, there's always a set of commands that can make the user go from
one representation to the other.  He just has to be careful and know
exactly which way the system will work.  Whichever way it works, it
should be clearly and carefully documented in the ALTER TABLE reference.

-- 
Alvaro Herrera (<alvherre[a]atentus.com>)
"Cuando no hay humildad las personas se degradan" (A. Christie)



pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: DROP COLUMN misbehaviour with multiple inheritance
Next
From: Joe Conway
Date:
Subject: news.postgresql.org down