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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
