On Wed, Oct 30, 2013 at 5:32 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > "MauMau" <maumau...@gmail.com> writes: >> From: "Tom Lane" <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
