Skip site navigation (1) Skip section navigation (2)

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

From: Thomas Hallgren <thomas(at)tada(dot)se>
To: mark(at)mark(dot)mielke(dot)cc
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>,"A(dot)M(dot)" <agentm(at)themactionfaction(dot)com>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fixed length datatypes. WAS [GENERAL] UUID's as
Date: 2006-06-29 07:12:32
Message-ID: 44A37D60.4060608@tada.se (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-hackers
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


In response to

Responses

pgsql-hackers by date

Next:From: Christopher Kings-LynneDate: 2006-06-29 07:16:49
Subject: Re: Fixed length datatypes. WAS [GENERAL] UUID's as
Previous:From: Thomas HallgrenDate: 2006-06-29 07:02:38
Subject: Re: Fixed length datatypes. WAS [GENERAL] UUID's as

pgsql-general by date

Next:From: Christopher Kings-LynneDate: 2006-06-29 07:16:49
Subject: Re: Fixed length datatypes. WAS [GENERAL] UUID's as
Previous:From: Thomas HallgrenDate: 2006-06-29 07:02:38
Subject: Re: Fixed length datatypes. WAS [GENERAL] UUID's as

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group