From: Josh Berkus <josh@agliodbs.com>
Reply-To: josh@agliodbs.com
Organization: Aglio Database Solutions
To: pgsql-hackers@postgresql.org
Subject: Re: uuid type for postgres
Date: Wed, 7 Sep 2005 11:31:16 -0700
User-Agent: KMail/1.8
Cc: nathan wagner <nw@hydaspes.if.org>
References: <20050906135057.GA24136@granicus.if.org>
	<200509070948.08307.josh@agliodbs.com>
	<20050907171912.GA6427@granicus.if.org>
In-Reply-To: <20050907171912.GA6427@granicus.if.org>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <200509071131.17161.josh@agliodbs.com>

Nathan,

> I was thinking of cryptographic applications. =A0Then, to use an
> example from another domain, initial TCP sequence numbers should
> be random (i.e. unguessable). =A0A problem with TCP perhaps. =A0It's
> been a while since i've read over my copy of _Applied Cryptography_,
> but I seem to recall that unguessable numbers were sometimes useful.

Yeah, the problem is what it does to your data.   If there's no analyzable=
=20
correspondence between the key and the server/table/row it attaches to,=20
then you have no way to detect if the key and the data have become=20
disassociated. =20

This is, btw, a problem with conventional SERIALs as well.   "unguessable"=
=20
UUIDs just compound the problem by adding additional variables (the server=
=20
and the table), as well as generally leading to applications which depend=20
*entirely* on UUID-based integrity and thus can't cope with any failures=20
in UUID generation or transmission.

I'm also a little baffled to come up with any real application where making=
=20
an id number for most tables "unguessable" would provide any kind of real=20
protection not far better provided by other means.   For your "users"=20
table, sure, but that's a very special case.

=2D-=20
=2D-Josh

Josh Berkus
Aglio Database Solutions
San Francisco