Attached is a reasonably complete working-out of my earlier proposal to
prevent OID collisions by probing catalogs' OID indexes and advancing to
the next OID whenever there is a duplicate. The code is driven by the
existence of a unique index, and so it is possible for users to take
advantage of the feature too:
create table foo(...) with oids;
create unique index foo_oid on foo(oid);
I'm not sure if we really want to document that though, as the
implementation will perform poorly when there are long runs of
consecutive OIDs in the table. This is relatively unlikely in the
system catalogs but seems quite probable in a user table.
The patch also removes CheckMaxObjectId, which seems no longer needed.
If we commit it, we should remove the code in pg_dump that tries to
set the OID counter, since that'd be dead code; but I didn't include
that change in this patch. Documentation updates are lacking too.
In principle I think this could be back-patched as far as 7.2, since
RelationGetIndexList exists that far back, but of course it needs a
good deal of testing before we even think about that. (There are a
couple of aspects that depend on the recent changes to have fixed,
preassigned OIDs for system catalogs, and we'd have to tweak those
areas to make a back-patch.)
Comments?
regards, tom lane
