Re: [PATCHES] Patch for UUID datatype (beta)

From: mark(at)mark(dot)mielke(dot)cc
To: Gregory Stark <gsstark(at)mit(dot)edu>
Cc: andrew(at)supernews(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCHES] Patch for UUID datatype (beta)
Date: 2006-09-20 13:17:52
Message-ID: 20060920131752.GA2410@mark.mielke.cc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

On Wed, Sep 20, 2006 at 05:04:00AM -0400, Gregory Stark wrote:
> mark(at)mark(dot)mielke(dot)cc writes:
> > I have the impression I'm not being heard.
> > *I* control the MAC address assignment for all of *MY* units.
> No, you're missing the point. How does that help *me* avoid collisions with
> your UUIDs? UUIDs are supposed to be unique period, not just unique on your
> database.

As you already said, they can't be. I don't see how random is better than
unique by intent (MAC address).

> If all you want is unique number generation in your database then
> you can just use sequences and they'll take a lot less space and
> perform much better. (16-byte foreign keys throughout the whole
> database, *shudder*)

I want unique number generation from several separate databases, and
I don't like the idea of maintaining complicated SERIAL ranges, or using
one of the increment by X, offset Y techniques. Too hard.

> The reason to use UUIDs is when you want to have unique identifiers that you
> can send outside the database and know they won't conflict with other unique
> identifiers generated elsewhere.

If you don't control the factors that influence the UUID generation, this
is a cross your fingers type of merge. Random numbers might collide.
Shared MAC address might collide. Not controlling the time source might
collide. Although it will probably work, if I know my domain, if I know
what will need to be merged, I can ensure that they can be merged.

> Really this whole debate only reinforces the point that there isn't
> a single way of doing UUID generation. There are multiple libraries
> out there each with pros and cons. It makes more sense to have
> multiple pgfoundry UUID generating modules.

Exactly. If I lead you to the impression that I want UUIDv1 in core, this
was not the intent. What I intend to say is that different people want
different implementations, and one of the most useful versions, in my
opinion, is difficult to implement portably.

Cheers,
mark

--
mark(at)mielke(dot)cc / markm(at)ncf(dot)ca / markm(at)nortel(dot)com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada

One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...

http://mark.mielke.cc/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stijn Vanroye 2006-09-20 13:47:51 Re: pdfs of the conference
Previous Message Simon Riggs 2006-09-20 13:09:43 Re: [HACKERS] Incrementally Updated Backup

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Dunstan 2006-09-20 14:06:26 Re: [PATCHES] Patch for UUID datatype (beta)
Previous Message Simon Riggs 2006-09-20 13:09:43 Re: [HACKERS] Incrementally Updated Backup