Re: [PATCH] pgcrypto: implement gen_random_uuid

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: emre(at)hasegeli(dot)com
Cc: Oskari Saarenmaa <os(at)ohmu(dot)fi>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] pgcrypto: implement gen_random_uuid
Date: 2014-01-17 20:42:01
Message-ID: 11392.1389991321@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Emre Hasegeli <emre(at)hasegeli(dot)com> writes:
> 2014/1/9 Oskari Saarenmaa <os(at)ohmu(dot)fi>:
>> The only useful feature of the uuid-ossp module in my opinion is the
>> uuid_generate_v4 function and as uuid-ossp is more or less abandonware
>> people have had trouble building and installing it. This patch implements
>> an alternative uuid v4 generation function in pgcrypto which could be moved
>> to core once there's a core PRNG with large enough internal state.

> It is a small but very useful patch. Installing uuid-ossp can be very hard
> on some systems. There is not much to review. The patch applies cleanly to
> HEAD. The function is generating valid UUID version 4. The code and
> the documentation style seems to fit in the pgcrypto extension. I am marking
> it as "Ready for Commiter".

> The problem is users probably would not look pgcrypto extension for
> UUID generator, especially when there is another extension with uuid in
> it's name. Also, UUID generator does not sound like a cryptographic function.
> It would be much better, if this would be in core with the UUID type. There
> is a reference on the UUID Type documentation page to the uuid-ossp
> extension. We can add a reference to pgcrypro extension in that page and
> consider adding a deprecation note to the uuid-ossp extension, if is is not
> possible to add the function to the core, for now.

Well, we're not pulling pgcrypto into core in the foreseeable future;
there are legal (export control) issues that make that too risky.
Even aside from that, there was general consensus when type uuid went
in that the various generation algorithms were, how shall I say it, too
intellectually unsatisfying to be part of the core code. So I think from
a code standpoint this solution is just fine. I agree that we need some
extra work on the documentation to point people towards this approach
instead of uuid-ossp, though. I'll take care of that and commit.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Florian Pflug 2014-01-17 21:17:02 Re: [PATCH] Negative Transition Aggregate Functions (WIP)
Previous Message Gregory Smith 2014-01-17 20:24:01 Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance