Re: uuid type for postgres

On Tue, Sep 06, 2005 at 05:54:34PM -0400, tgl@sss.pgh.pa.us wrote:
> One thing that is raising my own level of concern quite a bit is the
> apparent portability issues.

I can't speak to the portability in general, but there is a PORTING file
in the ossp uuid library that states

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)

On my end I managed to compile it with nothing more than a "configure",
"make", followed by a "make install".

> Code that isn't completely portable is a huge maintainability problem; in
> particular, stuff that requires system-dependent behavior used nowhere
> else in Postgres is a real pain. It sounds like the UUID code expects to
> be able to get at the machine's MAC address,

If the mac address isn't available, I believe it falls back on using
a random 47 bit number with the 48th bit set to make the mac address
fall within the multicast mac numberspace.  You could also use a version
4 uuid, or derive a version 3 or 5 uuid from some other source.

The better answer though, is these sort of questions are exactly why
I would prefer to rely on someone else's library.  Just as I basically
trust that the folks maintaining postgres aren't going to munge my tables
and destroy my data if i mess up a transaction and roll it back,
because they've spent time thinking about just that sort of problem, I
also (having worked with the code a bit now) trust the UUID folks
to have thought about "just how do we make a unique number without
centralized coordination?"  "base on the mac address?"  "what if we
don't have one?  or don't know it for some reason?"  I assume here that
the answer they came up with wasn't "oh, hell, just return a 42 then".

The point being, that other people have already written a better uuid
library than i am likely to, so, license permitting, let's use it.

> The bottom line is that we're willing to listen, but it's not by any
> means a slam dunk to get this into the distribution.

Fair enough.

Personally, I think it should be a core type, but would be quite happy
if it were in contrib.  At least that way it would save the next guy
from having to hunt around the net.

I guess i'm volunteering to maintain it in contrib.  I'm not certain
if i have the requisite knowledge to maintain it in the core.  While
I could acquire the familiarity if need be, for the next year and nine
months law school is going to take up the bulk of my free time.  And
of course I'll still need time to play around with my ticketing and gis
databases i'm developing.

-- 
Nathan Wagner