Re: [HACKERS] Well, then you keep your darn columns
От | Hannu Krosing |
---|---|
Тема | Re: [HACKERS] Well, then you keep your darn columns |
Дата | |
Msg-id | 388CC987.B5B86454@tm.ee обсуждение исходный текст |
Ответ на | Re: [HACKERS] Well, then you keep your darn columns (The Hermit Hacker <scrappy@hub.org>) |
Ответы |
Re: [HACKERS] Well, then you keep your darn columns
|
Список | pgsql-hackers |
The Hermit Hacker wrote: > > On Mon, 24 Jan 2000, Adriaan Joubert wrote: > > > As a user let me just say that I have been waiting for all the > > 'ALTER TABLE..' commands for a long time (changing constraints would be great > > too!) and it has been mentioned many times that one should not use oids in > > application code. The way I do it at the moment is to copy the table, so I > > think all users are used to losing their oids when remocing a column from a > > table. So while it is certainly better to keep the oids, Peter's code is a > > big improvement on the current situation. > > Except, as Chris Bitmead brought up, OIDs appear to be a key requirement > in ODBMSs ... so, if we want to go what I *think* is 'next generation', > OIDs have to be kept ... But the decision was (from Vadim IIRC) to drop them, at least in non system tables. The cited reasons were: * crappy implementation that taxed performance (probably fixed by now) * nobody else seemed to have them and the push then was to the direction of mainstream bean-counting DB with main objectiveof getting that base functionality right. * they take up "too much" space (probably a non-issue in current world of dropping disk/memory prices) * you can always re-implement them at the application level (the same was cited for dropping time travel) If it is now a general opinion that OIDs will remain, it should be stated somewhere, as I suspect that much of pg community operates under the impression that they are going away in future as have some other nice but not fully developed features like time travel. I do understand that time travel could be implemented using a bunch of rules+views but to be really useful rules views should be much more developed and integrated with inheritance, up to the level where you could say: create table stock( item_id int, quantity int, price numeric(15,2) ) inherits (time_travel); and then have all the needed tables/rules/views produced automatically. If we had that level of sofistication we could also safely drop OIDs as a built-in system feature and still have it by changing the last line to ) inherits (time_travel,odbms_table); ----------------- Hannu
В списке pgsql-hackers по дате отправления: