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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
