From: Josh Berkus <josh@agliodbs.com>
Reply-To: josh@agliodbs.com
Organization: Aglio Database Solutions
To: Bob Ippolito <bob@redivi.com>
Subject: Re: uuid type for postgres
Date: Tue, 6 Sep 2005 18:02:50 -0700
User-Agent: KMail/1.8
Cc: jonah.harris@gmail.com, pgsql-hackers@postgresql.org,
	mark@mark.mielke.cc, nathan wagner <nw@hydaspes.if.org>
References: <20050906135057.GA24136@granicus.if.org>
	<36e6829205090612575b954f38@mail.gmail.com>
	<3F60E55D-B558-4929-B614-C230EACFF473@redivi.com>
In-Reply-To: <3F60E55D-B558-4929-B614-C230EACFF473@redivi.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <200509061802.51089.josh@agliodbs.com>

Bob, People,

Let me clarify my stance here, because it seems to be getting=20
misrepresented.

Mark (and Nathan) pushed at repaired UUID type for possible inclusion in=20
the core PostgreSQL distribution.  I'm not opposed to that, provided that=20
the portability, licensing, and bugs are worked out.  Why not?  We have=20
ipv6 data types, after all.

However, Mark went on to suggest that we should recommend UUID over SERIAL=
=20
in the docs, and that we could consider dropping SERIAL entirely in favor=20
of UUID:

=2D--quoth Mark------------------
I suggest that UUID be recommended in place of SERIAL for certain
classes of applications, and that it therefore belongs in the core.
UUID and SERIAL can be used together (although, once you have a =C2=A0
UUID, it may not be useful to also have a SERIAL).
=2D--------------------------------

This was what I objected to; I believe that the use-case for UUIDs is=20
actually quite narrow and assert that it's a very bad idea to promote them=
=20
to most users.  =20

I have a "problem" with SERIAL abuse, too.   In general, new DB designers=20
have come to increasingly believe that surrogate keys (SERIALs, UUIDs,=20
hash ids etc.) are an intrinsic part of the relational model and a=20
requirement for all tables.   Terrible database designs have resulted,=20
chock full of tables which lack real keys and cannot be normalized.

UUIDs tend to encourage this sort of behavior even more than SERIALs, not=20
because of any intrinsic quality in the data type, but because much of the=
=20
literature on the subject treats them like some kind of "universal object=20
identifier" and not distinguishing servers, relations, or real keys. =20

To repeat, though, this isn't a reason to keep them out of core, but it=20
*is* a reason not to throw them at newbies as the holy grail of row=20
identifiers.

=46or my part, I generally push implementing the UUID concept in a better w=
ay=20
that keeps server, table, and surrogate keys atomic (and thus more useful=20
and easier to debug).

=2D-=20
=2D-Josh

Josh Berkus
Aglio Database Solutions
San Francisco