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  (The Hermit Hacker <scrappy@hub.org>)
Список 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 по дате отправления:

Предыдущее
От: Don Baccus
Дата:
Сообщение: Re: [HACKERS] Well, then you keep your darn columns
Следующее
От: Hannu Krosing
Дата:
Сообщение: Re: [HACKERS] Well, then you keep your darn columns