Michael Paquier <michael@paquier.xyz> writes:
> On Wed, Dec 26, 2018 at 01:45:00PM -0500, Tom Lane wrote:
>> A quick grep says that there's a dozen or so callers, so this patch
>> certainly isn't the only offender ... but should we make an effort
>> to convert them all to use, say, pg_erand48()? I think all the
>> existing callers could happily share a process-wide random state,
>> so we could make a wrapper that's no harder to use than random().
> Another possibility would be to extend a bit more the use of
> pg_strong_random(), though it is designed to really be used in cases
> like authentication where the random bytes are strong for
> cryptography. pg_erand48() would be a good step forward.
I think pg_strong_random is overkill, and overly expensive, for
most if not all of the existing callers of random(). We already
changed the ones where it's important to be strong ...
One thing I was wondering is if we should try to enforce a policy
like this by putting, say,
#define random() pg_random()
into port.h or so. That would have the advantages of not having to touch
any existing calls and not having to worry too much about future patches
breaking the policy. On the other hand, it's conceivable that third-party
extensions might get annoyed with us for hijacking a libc function.
Thoughts?
regards, tom lane
