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: Gevik Babakhani <pgdev(at)xs4all(dot)nl>
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>,pgsql-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] Patch for UUID datatype (beta)
Date: 2006-09-18 21:00:22
Message-ID: 20060918210021.GE47167@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
If you're going to yank it, please at least include a generator in
contrib.

Personally, I'd like to see at least some kind of generator in core,
with appropriate info/disclaimers in the docs. A simple random-number
generator is probably the best way to go in that regard. I think that
most people know that UUID generation isn't 100.00000% perfect.

BTW, at a former company we used SHA1s to identify files that had been
uploaded. We were wondering on the odds of 2 different files hashing to
the same value and found some statistical comparisons of probabilities.
I don't recall the details, but the odds of duplicating a SHA1 (1 in
2^160) are so insanely small that it's hard to find anything in the
physical world that compares. To duplicate random 256^256 numbers you'd
probably have to search until the heat-death of the universe.

On Mon, Sep 18, 2006 at 05:14:22PM +0200, Gevik Babakhani wrote:
> Completely agreed. I can remove the function from the patch. The
> temptation was just too high not to include the new_guid() in the
> patch :)
> 
> 
> On Mon, 2006-09-18 at 10:33 -0400, Tom Lane wrote: 
> > Andreas Pflug <pgadmin(at)pse-consulting(dot)de> writes:
> > > Isn't guaranteed uniqueness the very attribute that's expected? AFAIK
> > > there's a commonly accepted algorithm providing this.
> > 
> > Anyone who thinks UUIDs are guaranteed unique has been drinking too much
> > of the kool-aid.  They're at best probably unique.  Some generator
> > algorithms might make it more probable than others, but you simply
> > cannot "guarantee" it for UUIDs generated on noncommunicating machines.
> > 
> > One of the big reasons that I'm hesitant to put a UUID generation
> > function into core is the knowledge that none of them are or can be
> > perfect ... so people might need different ones depending on local
> > conditions.  I'm inclined to think that a reasonable setup would put
> > the datatype (with input, output, comparison and indexing support)
> > into core, but provide a generation function as a contrib module,
> > making it easily replaceable.
> > 
> > 			regards, tom lane
> > 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
> 

-- 
Jim Nasby                                    jimn(at)enterprisedb(dot)com
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)

In response to

Responses

pgsql-hackers by date

Next:From: Merlin MoncureDate: 2006-09-18 21:06:09
Subject: Re: 8.2 beta blockers
Previous:From: Martijn van OosterhoutDate: 2006-09-18 21:00:01
Subject: Re: minor feature request: Secure defaults during

pgsql-patches by date

Next:From: Martijn van OosterhoutDate: 2006-09-18 21:13:27
Subject: Re: [HACKERS] Patch for UUID datatype (beta)
Previous:From: Euler Taveira de OliveiraDate: 2006-09-18 18:33:17
Subject: cosmetic change in 'drop owned' reference

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