Re: [HACKERS] Well, then you keep your darn columns
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] Well, then you keep your darn columns |
Дата | |
Msg-id | 200001242037.PAA16128@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Well, then you keep your darn columns (The Hermit Hacker <scrappy@hub.org>) |
Ответы |
Re: [HACKERS] Well, then you keep your darn columns
|
Список | pgsql-hackers |
> > The only drawback of this scheme is that the space occupied by the > > deleted column wouldn't go away immediately (in any given tuple, > > it'd be reclaimed on the next UPDATE of the tuple). On the other hand, > > you could construe that as a feature --- you don't have to wait around > > for a DROP COLUMN to finish. Anyone who did want to reclaim space > > immediately could do > > UPDATE table SET someothercolumn = someothercolumn; > > followed by a VACUUM. But I bet a lot of people would be just as > > happy to let it happen in background. > > Hey Bruce ... Look here ^^^^ :) > > Oh, there is a second drawback to it though ... > > DROP COLUMN name > ADD COLUMN name <of a different type> > > Then what? :( Double-yikes. There goes that idea, or does it? Attributes are numbered. How does a missing attribute get handled for new rows? My guess is that we have to keep this thing around forever. Can you imagine having all those user apps tha query pg_attribute supress that column. Sound like too much work to me. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: