RE: ALTER TABLE DROP COLUMN
От | Hiroshi Inoue |
---|---|
Тема | RE: ALTER TABLE DROP COLUMN |
Дата | |
Msg-id | EKEJJICOHDIEMGPNIFIJEELACBAA.Inoue@tpf.co.jp обсуждение исходный текст |
Ответ на | Re: ALTER TABLE DROP COLUMN (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
RE: ALTER TABLE DROP COLUMN
Re: ALTER TABLE DROP COLUMN Re: ALTER TABLE DROP COLUMN |
Список | pgsql-hackers |
> -----Original Message----- > From: pgsql-hackers-owner@hub.org > [mailto:pgsql-hackers-owner@hub.org]On Behalf Of Bruce Momjian > > Seems we have 4 DROP COLUMN ideas: > > Method Advantage > ----------------------------------------------------------------- > 1 invisible column marked by negative attnum fast > 2 invisible column marked by is_dropped column fast > 3 make copy of table without column col removed > 4 make new tuples in existing table without column col removed > > Folks, we had better choose one and get started. > > Number 1 Hiroshi has ifdef'ed out in the code. Items 1 and 2 have > problems with backend code and 3rd party code not seeing the dropped > columns, Hmm,doesn't *not seeing* mean the column is dropped ? > or having gaps in the attno numbering. Number 3 has problems > with making it an atomic operation, and number 4 is described below. > Don't forget another important point. Currently even DROP TABLE doesn't remove related objects completely. And I don't think I could remove objects related to the dropping column completely using 1)2) in ALTER TABLE DROP COLUMN implementation. Using 3)4) we should not only remove objects as 1)2) but also change attnum-s in all objects related to the relation. Otherwise PostgreSQL would do the wrong thing silently. Regards. Hiroshi Inoue Inoue@tpf.co.jp
В списке pgsql-hackers по дате отправления: