Alvaro Herrera <alvhe...@2ndquadrant.com> writes:
> 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).
Not that way, anyway.
> 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.
My point is a bit more subtle than that. It's perfectly reasonable to
want a universally-unique identifier in some applications. The problem
is that there is no perfect implementation, and so people really need
to stop and think about which generator algorithm they're going to use
and whether its particular failure modes are acceptable in their
context. So I'm not eager to provide some "easy to use" API that
encourages users to believe that no thought is required on their part.
Having said that, though, the argument around whether such facilities
belong in core seems to devolve to whether you want to buy into
maintaining libuuid for ourselves (in fact worse than that: it's not clear
that libuuid ever has worked on all our platforms, so we might be buying
into some up-front porting work too). As Josh notes, we may be forced
into that anyway if we don't want to walk away from contrib/uuid-ossp.
But first I'd like to see a bit more research into what the alternatives
might be...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
