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

From Hannu Krosing
Subject Re: DROP COLUMN misbehaviour with multiple inheritance
Date
Msg-id 1031844221.29045.16.camel@taru.tm.ee
Whole thread Raw
In response to Re: DROP COLUMN misbehaviour with multiple inheritance  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: DROP COLUMN misbehaviour with multiple inheritance  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: DROP COLUMN misbehaviour with multiple inheritance  (Alvaro Herrera <alvherre@atentus.com>)
List pgsql-hackers
On Thu, 2002-09-12 at 16:14, Tom Lane wrote:
> Hannu Krosing <hannu@tm.ee> writes:
> > I've come upon a misbehaviour of drop column, where drop column
> > unconditionally drops inherited column from child tables.
> > What it should do is to check if the same column is not inherited from
> > other parents and drop it only when it is not
> 
> Hm.  Seems like attisinherited should have been a count, not a boolean.

either that, or some check at drop column time.
> Is anyone sufficiently excited about this issue to force an initdb to
> fix it?

The count approach seems definitely the right way, but a check (possibly
a slow one) can be probably done without initdb.

The other sad thing about the current behaviour is that in addition to
being wrong it also breaks dump/reload - after dump/reload the initially
dropped column is back in c1.

-------------
Hannu



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: DROP COLUMN misbehaviour with multiple inheritance
Next
From: Tom Lane
Date:
Subject: Re: OPAQUE and 7.2-7.3 upgrade