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