OIDs *can* get re-used *IF* you end up having more than 32-bits (2
billion plus) of objects in the lifetime of your application.
For normal usage, that ain't a big problem, honestly...
Though I should have stated it for the record, cuz maybe the OP has a
site where 2 BILLION INSERTs are gonna happen.
... 4 billion (I'm assuming the postgresql guys are smart enough to use
unsigned integers) isn't really as much as it looks. Remember this is
shared amongst all the tables in your database making these oids even
more of a precious resource ...
The solutions there are the same as for not having OID in the first
place -- Have some other unique identifier you generate yourself in the
INSERT, or use that *with* the OID to be 100% certain you get back the
same row from your 2 billion plus data set.
... and that's exactly what sequences are for. And that's why using oids
for a unique id is not a smart choice when sequences are available and
were designed explicitly to provide unique ids.
Just for some added info... from the FAQ:
http://www.postgresql.org/docs/faqs.FAQ.html#4.12
4.12) What is an OID? What is a CTID?
Every row that is created in PostgreSQL gets a unique OID unless created
WITHOUT OIDS. OIDs are autotomatically assigned unique 4-byte integers
that are unique across the entire installation. However, they overflow at
4 billion, and then the OIDs start being duplicated. PostgreSQL uses OIDs
to link its internal system tables together.
To uniquely number columns in user tables, it is best to use SERIAL rather
than OIDs because SERIAL sequences are unique only within a single table.
and are therefore less likely to overflow. SERIAL8 is available for
storing eight-byte sequence values.
CTIDs are used to identify specific physical rows with block and offset
values. CTIDs change after rows are modified or reloaded. They are used by
index entries to point to physical rows.
========
I seem to remember reading that PostgreSQL is going to get rid of OIDS
entirely sometime in the future, but I can't find anything right now to
confirm that... (too lazy to look)
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
