Bo Lorentsen <bl@netgroup.dk> writes:
> On Wed, 2003-09-03 at 11:10, Shridhar Daithankar wrote:
>> 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.
The reason OIDs shouldn't be considered unique is that there is no
mechanism to enforce that they are unique --- unless you make one,
that is, create a unique index on OID for a table. The system does
not do that for you since it would be excessive overhead for tables
in which the user doesn't care about OID uniqueness. But I'd
definitely recommend it if you are using OIDs for row identifiers.
If you want a globally unique ID based on OIDs, use the table OID
concatenated with the row OID.
I don't foresee OIDs going away in the future, because they are used
internally by the system; but I don't foresee them being "improved"
either. Serial columns already do much of what people would like from
OIDs, and the developers' response to all questions along this line
is likely to be "use a serial column instead". It's possible that the
default for table creation will switch to WITHOUT OIDS at some future
time, though I don't consider that a done deal because of the backwards
compatibility issue.
> There must be an internal oid
> somewhere, what we may be able to use.
No, there isn't. There is only ctid, which is not useful as a long-term
row identifier, because UPDATE and VACUUM can change it.
regards, tom lane