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.