Re: ALTER TABLE DROP COLUMN
От | Chris Bitmead |
---|---|
Тема | Re: ALTER TABLE DROP COLUMN |
Дата | |
Msg-id | 3944E560.D4CD71ED@bitmead.com обсуждение исходный текст |
Ответ на | Re: ALTER TABLE DROP COLUMN (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: ALTER TABLE DROP COLUMN
|
Список | pgsql-hackers |
I don't know if this is one of the 5, but my idea of a good implementation is to do the fast invisible approach, and then update individual tuples to the new format the next time they happen to be UPDATEd. Therefore, ALTER TABLE DROP COLUMN, followed by UPDATE foo SET bar=bar; would cause the equiv of (4). -- Chris Bitmead mailto:chris@bitmead.com Hannu Krosing wrote: > > Bruce Momjian wrote: > > > > 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 > > IIRC there was a fifth idea, a variation of 2 that would work better > with > inheritance - > > 5 all columns have is_real_column attribute that is true for all > coluns > present in that relation, so situations like > > create table tab_a(a_i int); > create table tab_b(b_i int) inherits(tab_a); > alter table tab_a add column c_i int; > > can be made to work. > > It would also require clients to ignore all missing columns that backend > can > pass to them as nulls (which is usually quite cheap in bandwith usage) > in > case of "SELECT **" queries. > > We could even rename attno to attid to make folks aware that it is not > be > assumed to be continuous. > > > 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, or having gaps in the attno numbering. > > If we want to make ADD COLUMN to work with inheritance wihout having to > rewrite every single tuple in both parent and inherited tables, we will > have to accept the fact that there are caps in in attno numbering. > > > Number 3 has problems > > with making it an atomic operation, and number 4 is described below. > > Nr 4 has still problems with attno numbering _changing_ during drop > which > could either be better or worse for client software than having gaps - > in both cases client must be prepared to deal with runtime changes in > attribute definition. > > -------------- > Hannu
В списке pgsql-hackers по дате отправления: