Re: Fixed length datatypes. WAS [GENERAL] UUID's as - Mailing list pgsql-hackers

On Wed, Jun 28, 2006 at 01:12:17PM -0500, Jim C. Nasby wrote:
> On Wed, Jun 28, 2006 at 01:49:55PM -0400, Andrew Dunstan wrote:
> > Personally I don't buy the misuse objection - we already have plenty of 
> > things that can be misused. As long as there is a reasonable valid use 
> > and we can make it portable enough, I think there is a good case for 
> > including it.
> Well, since Mark has one, how about we consider adding it in?
> If nothing else, can you please put your stuff on pgFoundry so others
> can find it, Mark?

It was written by Nathan Wagner <nw@hydaspes.if.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:
"Permission to use, copy, modify, and distribute this software for any purpose with or without fee is hereby granted,
providedthat the above copyright notice and this permission notice appear in all copies."
 

I haven't tested to see how portable the OSSP UUID implementation is.
This is their words:
"OSSP uuid was already written with maximum portability in mind, so there should be no great effort required to get it
runningon any Unix platform with a reasonable POSIX API. Additionally, the portability was tested by successfully
buildingand running it on the following particular Unix platforms (syntax is "<cpu>-<os> (<compiler>)"):
 
     alpha-tru644.0 (cc)     alpha-tru645.1 (gcc, cc)     hppa-hpux11.11 (cc)     ia64-hpux11.23 (cc)
ix86-debian2.2(gcc, icc)     ix86-debian3.0 (gcc)     ix86-debian3.1 (gcc)     ix86-freebsd4.9 (gcc)
ix86-freebsd5.2(gcc, icc)     ix86-netbsd1.6 (gcc)     ix86-qnx6.2 (gcc)     ix86-solaris10 (gcc)
ix86-unixware7.1.3(cc)     mips64-irix6.5 (gcc)     sparc64-solaris8 (gcc, forte)     sparc64-solaris9 (gcc)"
 

I've put it through a fair amount of testing, including using it
within compound indexes, expecting the index to be used for at
least '=', constructing many UUIDs quickly, in a sequence, and
converting it to and from string form. We chose to implement our
own encode / decode routines for performance reasons. With the
exception of testing it on a wider range of platforms, I would
call the module stable.

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.

Cheers,
mark

-- 
mark@mielke.cc / markm@ncf.ca / markm@nortel.com     __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada
 One ring to rule them all, one ring to find them, one ring to bring them all                      and in the darkness
bindthem...
 
                          http://mark.mielke.cc/