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
Re: [HACKERS] Well, then you keep your darn columns |
Список | 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 по дате отправления: