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

Re: DROP COLUMN misbehaviour with multiple inheritance

From: Alvaro Herrera <alvherre(at)atentus(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Hannu Krosing <hannu(at)tm(dot)ee>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: DROP COLUMN misbehaviour with multiple inheritance
Date: 2002-09-29 17:02:25
Message-ID: Pine.LNX.4.33.0209291257510.15588-100000@polluelo.lab.protecne.cl (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
On Sun, 29 Sep 2002, Tom Lane wrote:

> Hannu Krosing <hannu(at)tm(dot)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[(at)]dcc(dot)uchile(dot)cl>)
"Pido que me den el Nobel por razones humanitarias" (Nicanor Parra)


In response to

Responses

pgsql-hackers by date

Next:From: Hannu KrosingDate: 2002-09-29 17:05:55
Subject: Re: 7.2.3?
Previous:From: Alvaro HerreraDate: 2002-09-29 16:34:45
Subject: Re: pg_config : postgresql.conf adjustments?

pgsql-patches by date

Next:From: Hannu KrosingDate: 2002-09-29 17:29:32
Subject: Re: DROP COLUMN misbehaviour with multiple inheritance
Previous:From: Hannu KrosingDate: 2002-09-29 16:33:48
Subject: Re: DROP COLUMN misbehaviour with multiple inheritance

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