On 04/25/2014 11:46 AM, David Fetter wrote: > On Fri, Apr 25, 2014 at 10:58:29AM -0700, Josh Berkus wrote: >> You may say "oh, that's not the job of the identifer", but if it's not, >> WTF is the identifer for, then? > > Frequently, it's to provide some kind of opacity in the sense of not > have an obvious predecessor or successor.
A far better solution to that is to not share the unadorned ID with the user. Basically, there's two different reasons to offer UUIDs in PostgreSQL: 1) because they actually serve a useful purpose in providing a globally "unique" identifier; 2) because they work well with existing platforms and frameworks. Given the state of the art, the above two goals are separate and exclusive, apologists for poorly conceived UUID algorithms nonwithstanding. So either we provide a UUID type which actually helps identify unique entities between database servers, OR we supply a UUID which "just works" with popular web frameworks, or we supply both *as two or more different types*. But claiming that types chosen because they're popular are also technically sound is misleading at best. Further, based on our experience with OSSP, if we're going to make a UUId type in core because it's currently popular, we'd better be pretty sure that it's still going to be popular in 5 or 10 years from now. Otherwise we're better off keeping it an extension. I personally am interested in a UUID type which would support doing multi-master replication of JSON databases built on PostgreSQL, and will probably write one if nobody else does first, and I don't see existing, naive randomization-based UUIDS as ever filling that role adequately. Although, as I said, Andres' work in this area may have already taken care of this. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers