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

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(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:

"Permission to use, copy, modify, and distribute this software for
any purpose with or without fee is hereby granted, provided that
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 running on any Unix
platform with a reasonable POSIX API. Additionally, the portability
was tested by successfully building and 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(at)mielke(dot)cc / markm(at)ncf(dot)ca / markm(at)nortel(dot)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 bind them...

http://mark.mielke.cc/