Re: [HACKERS] Happy column dropping
От | Chris Bitmead |
---|---|
Тема | Re: [HACKERS] Happy column dropping |
Дата | |
Msg-id | 388BCBEF.615092D2@bitmead.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Happy column dropping (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-hackers |
Hannu Krosing wrote: > Putting something in a development tree can hardly be called a "release" > I'm sure many people would appreciate it even without "preserving oid-s" > as OID's are declared deprecated for (AFAIK) >2 years, I've never seen or heard of any mention of oids being "deprecated". Some people don't like them much, other people like them. Myself, I think they will be great when a few issues with them are cleaned up (e.g. backup with preservation of oids and full INSERT statements). > and they don't give > any real advantage over primary key with default nextval, as there are > currently no means for reasonably getting from oid to record. Not sure what you mean by "no means". They are queried and indexed like other fields. No advantage? Well it takes one less pg call to get the last value, and it takes less storage since they are there anyway. They will also be very important if and when postgres makes more moves toward being an ODBMS. BTW, if someone implememnted INSERT where you may optionally specify the oid, would this solve the problem, as I take it this patch is all about implementing drop column in terms of a CREATE/SELECT INTO.
В списке pgsql-hackers по дате отправления: