On Wed, Oct 30, 2013 at 5:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "MauMau" <maumau307@gmail.com> writes:
>> From: "Tom Lane" <tgl@sss.pgh.pa.us>
>>> Yeah, but what shall we replace it with? And can we preserve the
>>> API contrib/uuid-ossp offers? (Maybe we shouldn't even try, but
>>> just deprecate that module and start fresh.)
>
>> Would it be welcomed in this community if a patch for built-in UUID
>> generation functions are provided?
>
> Based on what? The reason we've held this code at arms length (in a
> contrib module) is exactly that we weren't too satisfied with the
> portability or adequacy of the generation methods. Moving the functions
> into core doesn't do anything to make that better; rather, it raises the
> portability bar even higher, as well as making it almost impossible to
> contemplate further API changes.
>
> Note the lack of enthusiasm for taking on maintainership of the OSSP
> code. Pushing it into core would mean that we're buying into that
> maintainership, hook line and sinker. I don't think that such a
> proposal would fly.
ISTM that the biggest problem is that we don't have a random number
generator which generates enough bits of randomness to implement
uuid_generate_v3. I think relatively few people would cry if we
didn't support uuid_generate_v1(), and the others all look simple
enough, provided there's somewhere to get lots of random bits.
On Linux, it seems like we could get those bits from /dev/urandom,
though I'm not sure how efficient that would be for the case where
many UUIDs are being generated at once. But that wouldn't be very
portable. It's tempting to think that we'd need a PRNG that generates
wider values, for which we might find other application also. But I'm
not volunteering to be the one to create such a thing.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
