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.33.0209291257510.15588-100000@polluelo.lab.protecne.cl
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>)
List pgsql-hackers
On Sun, 29 Sep 2002, Tom Lane wrote:

> Hannu Krosing <hannu@tm.ee> writes:
> > I'd propose that ADD ONLY would pull topmost attislocal up (reset it
> > from the (grand)child) whereas plain ADD would leave attislocal alone.
> 
> ADD ONLY?  There is no such animal as ADD ONLY, and cannot be because
> it implies making a parent inconsistent with its children.  (Yes, I
> know that the code takes that combination right now, but erroring out
> instead is on the "must fix before release" list.  Ditto for RENAME
> ONLY.)

I'm leaving right now and can't participate in the whole discussion, but
I implemented "ADD ONLY" as a way to add the column only in the parent
(all children should already have to column, errors if at least one
doesn't or is different atttype), while "ADD" adds the column to
children that don't have it and merges where already exist; it errors if
children have different atttype etc.

Should I rip the ADD ONLY part out?

-- 
Alvaro Herrera (<alvherre[@]dcc.uchile.cl>)
"Pido que me den el Nobel por razones humanitarias" (Nicanor Parra)



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: pg_config : postgresql.conf adjustments?
Next
From: Michael Meskes
Date:
Subject: Re: [ODBC] [s.hetze@linux-ag.de: PostgreSQL integration Visual Basic, SQLProcedureColumns]