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