In-Reply-To: <20050906220648.GD3069@mark.mielke.cc>
References: <20050906135057.GA24136@granicus.if.org>
	<20050906144930.GA27641@mark.mielke.cc>
	<200509061002.43803.josh@agliodbs.com>
	<36e6829205090612575b954f38@mail.gmail.com>
	<20050906203811.GA3069@mark.mielke.cc>
	<20921.1126043674@sss.pgh.pa.us>
	<20050906220648.GD3069@mark.mielke.cc>
Mime-Version: 1.0 (Apple Message framework v734)
Message-Id: <75CDCC93-EF09-4ED5-9770-55F49BF48614@redivi.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
	"Jonah H. Harris" <jonah.harris@gmail.com>, josh@agliodbs.com,
	pgsql-hackers@postgresql.org, nathan wagner <nw@hydaspes.if.org>
From: Bob Ippolito <bob@redivi.com>
Date: Tue, 6 Sep 2005 16:08:47 -0700
To: mark@mark.mielke.cc
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: uuid type for postgres


On Sep 6, 2005, at 3:06 PM, mark@mark.mielke.cc wrote:

> On Tue, Sep 06, 2005 at 05:54:34PM -0400, Tom Lane wrote:
>
>> I don't see any "big opposition".  People are simply questioning the
>> idea whether it belongs in core PG.  The reason we don't want to  
>> accept
>> everything-and-the-kitchen-sink in core is that we have only limited
>> manpower to maintain it.  So you've got to justify that we should  
>> spend
>> our effort here and not elsewhere.  There's a fair amount of nearly
>> ...
>> been there awhile.  So one of the questions that's going to be  
>> asked is
>> how useful/popular it's really going to be.
>>
>
> Sounds reasonable, and certainly no more than I expected. If Nathan
> hadn't raised the issue, it probably would have been a few months
> before I raised it myself.
>
>
>> One thing that is raising my own level of concern quite a bit is the
>> apparent portability issues.  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, which suggests serious issues in (a) relying on
>> not-too-standard APIs, (b) possible protection issues (will an
>> unprivileged process be able to get at the MAC address?), and (c)
>> ill-defined behavior on machines with more or less than one MAC  
>> address.
>> Not to mention that MAC addresses aren't so unique as all that.
>>
>
> I'll try to prepare an answer for this. (I started to write a lot of
> information - but is it unverified from memory, and perhaps should be
> more authoritative before presented as truth)

Some modern UUID implementations prefer /dev/urandom or similar to  
the time or MAC address unless you really beg them to give you a  
weaker UUID.

You can take a look at the man page for the Theodore Y. Ts'o  
implementation that is in Darwin's Libc here:
http://developer.apple.com/documentation/Darwin/Reference/ManPages/ 
man3/uuid_generate.3.html

Specifically:

        The uuid_generate function creates a new universally unique   
identifier
        (UUID).   The  uuid  will be generated based on high-quality  
randomness
        from  /dev/urandom,  if  available.   If  it  is  not   
available,  then
        uuid_generate  will use an alternative algorithm which uses  
the current
        time, the local ethernet MAC address (if available),  and   
random  data
        generated using a pseudo-random generator.

The Apache Portable Runtime has a apr_os_uuid_get() that supports two  
flavors of UUID for unix (Linux/Mac OS X uuid_generate and FreeBSD's  
uuid_create, may be available elsewhere), and the UuidCreate API on  
Win32.  apr-util's apr_uuid_get() will use apr_os_uuid_get() if  
available, and otherwise will default to a relatively weak mostly- 
timestamp-based UUID.

It would probably be reasonable and easy to do what Apache does  
here.  A platform UUID implementation, if present, is generally going  
to be better than anything included into PostgreSQL itself.

-bob