"Kevin Field" <kev@brantaero.com> writes:
> Either way, are 64-bit OIDs planned within the next couple years?
No, they're not planned at all. That line of thought has pretty much
died off, to the point where OIDs in user tables are not just deprecated
but not there at all by default.
There are basically two ways to attack the problem of a database-wide
unique ID:
* Use a single int8 sequence for the whole database;
* Use the combination of table OID and row OID (or, perhaps, an int8
sequence for the row identifier, if you need more than a billion or
so rows in the table).
The good thing about a two-part unique ID is that you can tell by
inspection which table the object is in, which is pretty handy.
But of course it's a bit ugly notationally, since you have to deal with
two fields not one.
The problem of dumping and restoring raw OIDs is still as bad as it was
in 2000. However there's now the "regclass" datatype that can provide
a symbolic display of table OID. If I were doing this today I'd use a
regclass column for the table part of a unique ID, and per-table serial
or bigserial counters for the row part.
regards, tom lane