Re: OID wraparound: summary and proposal

Hmm, this has proven more contentious than I expected ;-). It seems the
one thing that absolutely everybody agrees on is that 4-byte OIDs are no
longer workable as global identifiers.

My feeling after reading the discussions is that the best way to go
in the long run is to change from a database-wide OID generator to
per-table OID generators, and to say that if you want a database-wide
unique identifier then you should use <table oid, row oid> as that
identifier. If you want cluster-wide or universe-wide uniqueness then
you stick additional fields on the front of that. Unique IDs formed
in this way are a lot more useful than IDs taken from a simple global
sequence, because you can use the subfields to determine where to look
for the object.

If OID remains at 4 bytes then this still isn't very satisfactory for
tables that are likely to have more than 4 billion INSERTs in their
lifetime. However, rather than imposing the cost of 8-byte OIDs
everywhere, I'd be inclined to say that people who need unique
identifiers in such tables should use user-defined columns generated
from int8 sequences. (Obviously it would help if we created an
int8-based sequence type... but that's certainly doable.) Perhaps in
another few years, when all portability and performance issues with int8
are history, we could think about changing OID to 8 bytes everywhere;
but I don't think that's a good idea just yet.

I do not think it is feasible to try to implement per-table OID
generation for 7.2. What I'd like to do for 7.2 is continue with
my previous proposal of making OID generation optional on a per-table
basis (but the default is still to generate them). This seems to fit
well with an eventual migration to per-table OIDs, since it still seems
to me that some tables don't need them at all --- particularly, tables
that are using an int8 column as key because wraparound is expected.
Also, I will change pg_description as previously discussed, since this
is clearly necessary in a per-table-OID world.

Comments, objections?

regards, tom lane