From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
        Adrien Nayrat <adrien.nayrat@anayrat.info>,
        Thomas Munro <thomas.munro@enterprisedb.com>,
        Dmitry Dolgov <9erthalion6@gmail.com>,
        Tomas Vondra <tomas.vondra@2ndquadrant.com>,
        vik.fearing@2ndquadrant.com, Robert Haas <robertmhaas@gmail.com>,
        David Rowley <david.rowley@2ndquadrant.com>,
        Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: random() (was Re: New GUC to sample log queries)
In-reply-to: <20181227013458.GF2106@paquier.xyz>
References: <20181129214850.kiq6mvofsgplqjdr@alvherre.pgsql>
 <3859.1545849900@sss.pgh.pa.us> <20181227013458.GF2106@paquier.xyz>
Comments: In-reply-to Michael Paquier <michael@paquier.xyz>
	message dated "Thu, 27 Dec 2018 10:34:58 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <32695.1545875185.1@sss.pgh.pa.us>
Date: Wed, 26 Dec 2018 20:46:25 -0500
Message-ID: <32696.1545875185@sss.pgh.pa.us>
Precedence: bulk

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