"Kevin Field" <kev@xxxxxxxxxxxxx> 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
