Re: DROP COLUMN status
От | Wim Ceulemans |
---|---|
Тема | Re: DROP COLUMN status |
Дата | |
Msg-id | 393F4838.414FA2BA@nice.be обсуждение исходный текст |
Ответ на | RE: DROP COLUMN status ("Hiroshi Inoue" <Inoue@tpf.co.jp>) |
Ответы |
RE: DROP COLUMN status
|
Список | pgsql-hackers |
Hiroshi Inoue wrote: > > > -----Original Message----- > > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > > Sent: Thursday, June 08, 2000 1:58 PM > > > > [ Charset ISO-8859-1 unsupported, converting... ] > > > > -----Original Message----- > > > > From: pgsql-hackers-owner@hub.org > > [mailto:pgsql-hackers-owner@hub.org]On > > > > Behalf Of Bruce Momjian > > > > > > > > Can someone comment on where we are with DROP COLUMN? > > > > > > > > > > I've already committed my trial implementation 3 months ago. > > > They are $ifdef'd by _DROP_COLUMN_HACK__. > > > Please enable the feature and evaluate it. > > > You could enable the feature without initdb. > > > > OK, can you explain how it works, and add any needed documentation so we > > can enable it. > > > > First it's only a trial so I don't implement it completely. > Especially I don't completely drop related objects > (FK_constraint,triggers,views etc). I don't know whether > we could drop them properly or not. > > The implementation makes the dropped column invisible by > changing its attnum to -attnum - offset(currently 20) and > attnam to ("*already Dropped%d",attnum). It doesn't touch > the table at all. After dropping a column insert/update > operation regards the column as NULL and other related > stuff simply ignores the column. > If one would do a dump/restore of the db after dropping a column, is the column definitely gone then? Regards Wim Ceulemans
В списке pgsql-hackers по дате отправления: