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

From Hiroshi Inoue
Subject RE: [HACKERS] Well, then you keep your darn columns
Date
Msg-id NDBBIJLOILGIKBGDINDFAEFDCCAA.Inoue@tpf.co.jp
Whole thread Raw
In response to Well, then you keep your darn columns  (Peter Eisentraut <e99re41@DoCS.UU.SE>)
Responses Re: [HACKERS] Well, then you keep your darn columns
Re: [HACKERS] Well, then you keep your darn columns
List pgsql-hackers
> -----Original Message-----
> From: owner-pgsql-hackers@postgreSQL.org 
> [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Peter Eisentraut
> 
> Let me thank all of those that spoke up in my support and let me tell of
> those that were unhappy that I _will_ be here tomorrow as well. To
> summarize the points and add a few of my own:
> 
> 1) This is a TODO item.
> 
> 2) I have reviewed several mutterings about how to implement this in the
> archives and followed the consensus that you need to copy the table over
> somehow. It's not like I made this up.
> 
> 2a) Does anyone have a better idea? (Btw., I'm not too excited about
> by-passing the storage manager and writing around in the table file on
> disk. If vacuum does that, that doesn't mean it's the right thing to do.)
>

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. 

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: Bruce Momjian
Date:
Subject: Re: [HACKERS] column aliases
Next
From: Michael Robinson
Date:
Subject: Re: [HACKERS] fatal copy in/out error (6.5.3)