On 04/24/2014 08:23 PM, Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>> Heikki Linnakangas wrote:
>>> On 04/24/2014 08:00 PM, Alvaro Herrera wrote:
>>>> Tom Lane wrote:
>>>>
>>>>> This is not our fault, and I don't want us to get caught up in trying
>>>>> to fix a fundamentally broken concept --- which is what a generic
>>>>> "uuidserial" API would be. If you try to paper over the difficulties
>>>>> here, they'll just bite you on the rear someday.
>>>>
>>>> But we have non-colliding generation technology for OIDs in system
>>>> catalogs. We could try to reuse the idea in a UUID generator: grab one
>>>> value, try to insert; if it fails generate a new one, lather, rinse,
>>>> repeat.
>>>
>>> Umm, UUID stands for Universally Unique IDentifier. That would
>>> hardly be *universally* unique.
>>
>> I don't understand your point. I'm only replying to Tom's assertion
>> that UUID generation might not be all that unique after all (or, in
>> other words, AIUI, that the "universally unique" part of the name is
>> wishful thinking and not an actual property of the real thing.)
>
> Oh, I think I see your point: it's that no matter what we do here, there
> would be no way to guarantee that a value we generate does not collide
> with any other value elsewhere (either on other uuidserial columns, or
> on other servers).
>
> Is that it?
Yep.
> Because if it is, then I think the problem is that the UUID concept
> might be flawed yet users still want to use it, and we do no service by
> refusing to provide it on those grounds.
Well, we should make a reasonable effort to make them unique. If there
is a reliable-enough way to generate UUIDs that doesn't depend on
external libraries, by all means lets have it in core. I believe the
reason we put gen_random_uuid() in pgcrypto is that it needs a good
random number generator, and we don't trust plain old random() to be
good enough for that.
- Heikki
