Date: Wed, 7 Sep 2005 02:36:06 +0000
From: nathan wagner <nw@hydaspes.if.org>
To: pgsql-hackers@postgresql.org
Subject: Re: uuid type for postgres
Message-ID: <20050907023606.GA2181@granicus.if.org>
References: <20050906135057.GA24136@granicus.if.org>
	<200509061802.51089.josh@agliodbs.com>
	<20050907011135.GA7369@mark.mielke.cc>
	<200509061840.28068.josh@agliodbs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200509061840.28068.josh@agliodbs.com>
User-Agent: Mutt/1.4.2.1i

On Tue, Sep 06, 2005 at 06:40:27PM -0700, josh@agliodbs.com wrote:
 
> Sure.  What's a UUID, after all?   It's three pieces of information:
> 1) A server or database instance identifier
> 2) A table identifier
> 3) A row identifier
> 
> e.g.:
> chayote.sf.agliodbs.com | public.customers | 4271
> 
> Generally, it's pretty easy to just grab these 3 pieces of information 
> separately and pass them with the data when you want to transmit between 
> servers.  If there are space/overhead considerations, you can put them 
> into a reversable hash.

Take a look at the version 3 or version 5 UUIDs.  They essentially do this.
The hash isn't reversable, but rather recreatable.  Seems that if it
were reversable, it would be compression, not a hash.  Anyway.

You're assuming though that you want to leak this information.  If you do,
or you don't care, go ahead with the v3 or v5 uuid creator.

Or use v1 if you want mac/time based uuids, or v4 for random uuids.

The convenient thing about using the uuid library is that all of these
mechanisms result in the same type, and are thus compatible.

> I've never understood the complex measures which 
> application developers take to create "universal" IDs.

Different applications have different goals.  Unguessability might
be important in some contexts.

-- 
Nathan Wagner