Alvaro,
>> 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?
>
> 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.
It's more than that:
1) the concept of UUIDs is fundamentally flawed, to the extent that if
we have a UUID type in core its flaws become our flaws, to be handled in
bug reports forever.
2) Because the concept of UUIDs is flawed, there are multiple competing
implementations, none of which is clearly dominant and durable. As
such, any UUID algorithm we adopt for core stands a significant risk of
being later abandoned by everyone else and becoming a PostgreSQL wart.
3) In general, users who want UUIDs don't want a generic concept of
UUIDs; they want the specific UUIDs which work with their individual
programming languages, web frameworks, or queueing platforms. So, see
competing implementations above.
As case in point for (2), as I said upthread: uuid-ossp, which has been
our option for UUID in contrib since originally it was the only OSS
implementation, is now abandoned by everyone but us.
Additionally, were I to adopt a UUID scheme for PostgreSQL, I would want
to to be *for postgresql*, with components indicating server, table and
schema of origin for each ID. A pseudo-random UUID is frankly pretty
useless to me because (a) it's not really unique, and (b) it doesn't
help me route data at all.
Alternatively, what would be *really* useful is to have a way for an
extension to plug into the "serial" concept, so that it gets all of the
benefits of serial (permissions, dependancies, etc.) while being able to
call a custom generator function.
Oh, and:
4) IIRC, Andres has already worked out a scheme for distributed serials
to support BDR. So this is a solved problem for the only really
interesting use case ...
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
