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

Поиск
Список
Период
Сортировка
От Chris Bitmead
Тема Re: [HACKERS] Well, then you keep your darn columns
Дата
Msg-id 388CDE51.E5240641@bitmead.com
обсуждение исходный текст
Ответ на RE: [HACKERS] Well, then you keep your darn columns  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
Список pgsql-hackers
Hiroshi Inoue wrote:
> 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.

Hi all....

Can I just point out that the above is THE RIGHT THING(tm). I havn't
followed this thread from the beginning, but can I point out that
implementing drop column as a copy/rename is not good (better than
nothing I guess).

Take a cue from a database like VERSANT (http://www.versant.com). You
can change the database's schema while the database is running. Time
taken to delete a column is roughly 0.0 seconds no matter how large the
table. Going the whole hog, you keep the old schema available so that
when you retrieve an old tuple it can be updated the next time that
tuple is updated.


> 
> 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 по дате отправления:

Предыдущее
От: Philip Warner
Дата:
Сообщение: Re: AW: [HACKERS] Some notes on optimizer cost estimates
Следующее
От: Don Baccus
Дата:
Сообщение: Re: [HACKERS] Well, then you keep your darn columns