> > At the same time that we announce support for optional OIDs,
> > we should announce that, in future releases, OIDs will only be
> > guaranteed unique (modulo wraparounds) within a single table.
... if an appropriate unique constraint is explicitly created.
>
> Seems reasonable --- that will give people notice that we're thinking
> about separate-OID-generator-per-table ideas.
Imho we should think about adding other parts to the external representation
of OID before we start thinking about moving from 4 to 8 bytes in the heap.
Essentially the oid would then be a concatenated e.g. 16 byte number,
that is constructed with:
oid128 = installation oid<<96 + class oid<<64 + for_future_use<<32 + tuple oid
Imho walking that direction would serve the "OID" idea a lot better,
and could actually guarantee a globally unique oid, if the "installation
oid" was centrally managed.
It has the additional advantage of knowing the class by only looking at the oid.
The btree code could be specially tuned to only consider the lower 4(or 8) bytes
on insert and make an early exit for select where oid = wrong class id.
Andreas
