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