Re: [HACKERS] Re: ALTER TABLE DROP COLUMN - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: [HACKERS] Re: ALTER TABLE DROP COLUMN
Date
Msg-id 38BA43D0.559054E4@tm.ee
Whole thread Raw
In response to Re: [HACKERS] Re: ALTER TABLE DROP COLUMN  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Re: ALTER TABLE DROP COLUMN
List pgsql-hackers
Don Baccus wrote:
> 
> At 12:21 PM 2/28/00 +0900, Hiroshi Inoue wrote:
> 
> >My idea is essentially an invisible column implementation.
> >DROP COLUMN would change the target pg_attribute tuple
> >as follows..
> 
> I don't see such a solution as being mutually exclusive with
> the other one on the table.

Very true, and we will need the hidden columns feature for a clean 
implementation of inheritance anyway.

> Remember ... Oracle provides both.  I suspect that they did so
> because they were under customer pressure to provide a "real"
> column drop and a "fast" (and non-2x tablesize!) solution.  So
> they did both.  Also keep in mind that being able to drop a
> column in Oracle is a year 1999 feature ... and both are provided.
> More evidence of pressure from two points of view.
> 
> Of course, PG suffers because the "real" column drop is a 2x
> space solution, so the "invisibility" approach may more frequently
> be desired.

"update t set id=id+1" is also a 2x space, likely even more if 
referential inheritance is used (and checked at the end of transaction)

And my main use of DROP COLUMN will probably be during development, 
usually meaning small table sizes.

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


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
Next
From: Oleg Broytmann
Date:
Subject: Locale support broken in latest snapshots