mark(at)mark(dot)mielke(dot)cc wrote:
> 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.
>
One requirement would be that it runs on Windows. Is that something you have tested?
Regards,
Thomas Hallgren