Re: [HACKERS] Well, then you keep your darn columns - Mailing list pgsql-hackers

From Chris Bitmead
Subject Re: [HACKERS] Well, then you keep your darn columns
Date
Msg-id 388CDE51.E5240641@bitmead.com
Whole thread Raw
In response to RE: [HACKERS] Well, then you keep your darn columns  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
List pgsql-hackers
Hiroshi Inoue wrote:
> I propose another implementation here. I don't think this is so
> important a feature. I'm only afraid of forced implementation
> especially using copy() and rename() for such a feature.

Hi all....

Can I just point out that the above is THE RIGHT THING(tm). I havn't
followed this thread from the beginning, but can I point out that
implementing drop column as a copy/rename is not good (better than
nothing I guess).

Take a cue from a database like VERSANT (http://www.versant.com). You
can change the database's schema while the database is running. Time
taken to delete a column is roughly 0.0 seconds no matter how large the
table. Going the whole hog, you keep the old schema available so that
when you retrieve an old tuple it can be updated the next time that
tuple is updated.


> 
> My idea is as follows.
> 
> 1)add a visibile/invisible flag to pg_attribute
> 2)DROP COLUMN marks the column as invisible
> 3)user interface ignores the columns which are marked invisible
> 4)heap_formtuple() etc treats the column as NULL internally
> 
> Regards.
> 
> Hiroshi Inoue
> Inoue@tpf.co.jp
> 
> ************


pgsql-hackers by date:

Previous
From: Philip Warner
Date:
Subject: Re: AW: [HACKERS] Some notes on optimizer cost estimates
Next
From: Don Baccus
Date:
Subject: Re: [HACKERS] Well, then you keep your darn columns