Re: [HACKERS] Well, then you keep your darn columns
От | Hannu Krosing |
---|---|
Тема | Re: [HACKERS] Well, then you keep your darn columns |
Дата | |
Msg-id | 388CCF9F.809E93AC@tm.ee обсуждение исходный текст |
Ответ на | Re: [HACKERS] Well, then you keep your darn columns (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] Well, then you keep your darn columns
|
Список | pgsql-hackers |
Bruce Momjian wrote: > > > > 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> or the same type, it will be added at the end anyway. part of making it invisible should be making its _name_ invisible in pg_* one way would be to rename it to '\n'+str(next_available_oid) or sone other invalid column name. > > > > Then what? :( > > Double-yikes. There goes that idea, or does it? Attributes are > numbered. How does a missing attribute get handled for new rows? The proposition was to set it always to NULL (takes no additional storage if there are other null columns, (fieldcnt+31)/8 bytes else. BTW, the current handling of nulls in storage is a bit weird - the bitvector for null/not null starts at position 31, but if there is a bitmap space is allocated in 4-byte chunks starting at position 32 (at least on linux/x86) > My guess is that we have to keep this thing around forever. Or until dump/reload, the renumbering will be automatic there. > Can you > imagine having all those user apps tha query pg_attribute supress that > column. Sound like too much work to me. To me it sounds like a thing that _must_ be done at major number change, so 7.0 is a good place. OTOH, we could provide SQL92 ways for getting the info that current user apps get by querying pg_attribute. IIRC it requires a bunch of views on system tables, some of which could be lifted straight from psql's \d* commands. ----------------------------- Hannu
В списке pgsql-hackers по дате отправления: