Re: Proposal: OID wraparound: summary and proposal

I would just like to comment that for our project, GNU Enterprise, we
use our own 128 bit object ID that is unique (UUID) for every row in
all tables.

It seems to me, without having looked into it, that having both a
PostgreSQL UID and our own 128 bit objectid (UUID) is redundant and
slows the whole process down. But we are storing object data in the
database and require and absolutely unique objectid. We are planning
for enterprise usage and expect to need 128 bits to uniquely define
our objects.

So I would request strongly that we have an option for a 128 bit
unique id for all rows in the database and/or that it is configurable
so we can best decide how to use it. We would like to use our own
and have the postgreSQL uid fast and small or have it larger and
slower but remove the need to generate our own uid.

Neil
neilt(at)gnue(dot)org
GNU Enterprise
http://www.gnuenterprise.org/
http://www.gnuenterprise.org/~neilt/sc.html

At 10:17 AM +0200 8/3/01, Zeugswetter Andreas SB wrote:
> > > 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.