Skip site navigation (1) Skip section navigation (2)

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

From: "Jim C(dot) Nasby" <jimn(at)enterprisedb(dot)com>
To: mark(at)mark(dot)mielke(dot)cc
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org,Andreas Pflug <pgadmin(at)pse-consulting(dot)de>,Gevik Babakhani <pgdev(at)xs4all(dot)nl>,pgsql-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] Patch for UUID datatype (beta)
Date: 2006-09-19 14:16:31
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
On Tue, Sep 19, 2006 at 09:51:23AM -0400, mark(at)mark(dot)mielke(dot)cc wrote:
> On Tue, Sep 19, 2006 at 08:20:13AM -0500, Jim C. Nasby wrote:
> > On Mon, Sep 18, 2006 at 07:45:07PM -0400, mark(at)mark(dot)mielke(dot)cc wrote:
> > > I would not use a 100% random number generator for a UUID value as was
> > > suggested. I prefer inserting the MAC address and the time, to at
> > > least allow me to control if a collision is possible. This is not easy
> > > to do using a few lines of C code. I'd rather have a UUID type in core
> > > with no generation routine, than no UUID type in core because the code
> > > is too complicated to maintain, or not portable enough.
> > As others have mentioned, using MAC address doesn't remove the
> > possibility of a collision.
> It does, as I control the MAC address. I can choose not to overwrite it.
> I can choose to ensure that any cases where it is overwritten, it is
> overwritten with a unique value. Random number does not provide this
> level of control.
> > Maybe a good compromise that would allow a generator function to go into
> > the backend would be to combine the current time with a random number.
> > That will ensure that you won't get a dupe, so long as your clock never
> > runs backwards.
> Which standard UUID generation function would you be thinking of? 
> Inventing a new one doesn't seem sensible. I'll have to read over the
> versions again...

I don't think it exists, but I don't see how that's an issue. Let's look
at an extreme case: take the amount of random entropy used for the
random-only generation method. Append that to the current time in UTC,
and hash it. Thanks to the time component, you've now greatly reduced
the odds of a duplicate, probably by many orders of magnitude.

Ultimately, I'm OK with a generator that's only in contrib, provided
that there's at least one that will work on all OSes.
Jim Nasby                                    jimn(at)enterprisedb(dot)com
EnterpriseDB      512.569.9461 (cell)

In response to

pgsql-hackers by date

Next:From: Dave PageDate: 2006-09-19 14:23:56
Subject: Re: vista
Previous:From: Andrew DunstanDate: 2006-09-19 14:11:39
Subject: Re: [PATCHES] Patch for UUID datatype (beta)

pgsql-patches by date

Next:From: Albe LaurenzDate: 2006-09-19 14:33:57
Subject: Re: Dynamic linking on AIX
Previous:From: Andrew DunstanDate: 2006-09-19 14:11:39
Subject: Re: [PATCHES] Patch for UUID datatype (beta)

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group