RE: [HACKERS] Well, then you keep your darn columns

Поиск
Список
Период
Сортировка
От Hiroshi Inoue
Тема RE: [HACKERS] Well, then you keep your darn columns
Дата
Msg-id NDBBIJLOILGIKBGDINDFAEFDCCAA.Inoue@tpf.co.jp
обсуждение исходный текст
Ответ на Well, then you keep your darn columns  (Peter Eisentraut <e99re41@DoCS.UU.SE>)
Ответы Re: [HACKERS] Well, then you keep your darn columns  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: [HACKERS] Well, then you keep your darn columns  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] column aliases
Следующее
От: Michael Robinson
Дата:
Сообщение: Re: [HACKERS] fatal copy in/out error (6.5.3)