On Wed, 2003-09-03 at 11:10, Shridhar Daithankar wrote:
> Yes. It is correct. As of 7.3.x and onwards oids are optional at table creation
> times. They default to be available for new objects but that is for backwards
> compatibility I believe. In future, they would default to be not available for
> a particular object(hopefully). Right now you need to explicitly specify no
> oids while creating tables etc.
I do understand the limitation of the oid as implimented now, but why
remove the possibility to make unique row references (like after an
insert), instead of extenting the oid ?
I don't care if they wrap, or is a unique string or anything else, as
long as I can use it to refetch a row after an insert, without keeping
track of app. implimentation specific SERIAL fields.
> About oids not being unique, oids can assume 4 billion different values. If you
> have more than those many rows in a table, oids will wrap around and will no
> longer be unique in that object.
I see that this is a problem, and 4 billion is not alot, but why not
make another format like in oracle, so that it still is possible to
refere to a row using a unique --- thing. There must be an internal oid
somewhere, what we may be able to use.
> About oids being eliminated, I am sure it would happen some time in the future,
> looking at the development on this issue. Core team could elaborate more on
> this.
Sounds like a sad thing, if this is not replaced by something simular,
but more fit to a large DB.
/BL
