Re: [HACKERS] Re: ALTER TABLE DROP COLUMN

Поиск
Список
Период
Сортировка
От Hannu Krosing
Тема Re: [HACKERS] Re: ALTER TABLE DROP COLUMN
Дата
Msg-id 38BA43D0.559054E4@tm.ee
обсуждение исходный текст
Ответ на Re: [HACKERS] Re: ALTER TABLE DROP COLUMN  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] Re: ALTER TABLE DROP COLUMN
Список pgsql-hackers
Don Baccus wrote:
> 
> At 12:21 PM 2/28/00 +0900, Hiroshi Inoue wrote:
> 
> >My idea is essentially an invisible column implementation.
> >DROP COLUMN would change the target pg_attribute tuple
> >as follows..
> 
> I don't see such a solution as being mutually exclusive with
> the other one on the table.

Very true, and we will need the hidden columns feature for a clean 
implementation of inheritance anyway.

> Remember ... Oracle provides both.  I suspect that they did so
> because they were under customer pressure to provide a "real"
> column drop and a "fast" (and non-2x tablesize!) solution.  So
> they did both.  Also keep in mind that being able to drop a
> column in Oracle is a year 1999 feature ... and both are provided.
> More evidence of pressure from two points of view.
> 
> Of course, PG suffers because the "real" column drop is a 2x
> space solution, so the "invisibility" approach may more frequently
> be desired.

"update t set id=id+1" is also a 2x space, likely even more if 
referential inheritance is used (and checked at the end of transaction)

And my main use of DROP COLUMN will probably be during development, 
usually meaning small table sizes.

------------
Hannu


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] Beta for 4:30AST ... ?
Следующее
От: Oleg Broytmann
Дата:
Сообщение: Locale support broken in latest snapshots