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...
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 |
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 |