Re: Fixed length datatypes. WAS [GENERAL] UUID's as

mark(at)mark(dot)mielke(dot)cc wrote:
> On Thu, Jun 29, 2006 at 02:02:32AM -0400, mark(at)mark(dot)mielke(dot)cc wrote:
>> It was written by Nathan Wagner <nw(at)hydaspes(dot)if(dot)org> and myself, and
>> is based off the OSSP ( http://www.ossp.org/ ) UUID implementation.
>> I'm not an expert on the license, but it seems acceptable to me:
>> ...
>> If there is interest - I'm sure Nathan and I would be willing to put
>> it on pgfoundry, and at some point give it up for inclusion into
>> PostgreSQL.
>
> This might require a little bit of research. It appears that the
> development version of OSSP UUID may provide its own PostgreSQL
> 'bindings'. I may try and contact the author of the OSSP UUID and
> see whether any changes we have that he does not, can be rolled
> into his version...
>
> Cheers,
> mark
>
I'm thinking ahead on possible objections to inclusion in core. One objection might be that
a fully blown UUID implementation is a lot of code. Code that needs to be maintained and it
increases the size of the binary etc. A solution to that might be to break the whole thing
up in two:

1 The actual type
A plain scalar type that stores 16 bytes. It's complete with standard operators for
comparison (natural order) and the text representation would be a 32 character hexadecimal
string. This type should make no interpretation whatsoever on what it stores and its only
association with UUID's is the storage size.

2 UUID utilities
Various ways of representing, generating, and extract partial information from UUID's.
Should have support for variants #0, #1, and #2 (the OSSP based code sounds like a good
candidate).

The split make sense since clients often have powerful UUID utilities handy and hence have
limited or no use for such utilities in the database (true for all .NET and Java clients).
Some PL's will also enable such packages out of the box.

The actual type would be extremely generic, lightweight, and easy to implement. No
portability issues whatsoever. The only difficulty that I see is naming it :-).

Regards,
Thomas Hallgren