From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Adrien Nayrat <adrien(dot)nayrat(at)anayrat(dot)info>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, vik(dot)fearing(at)2ndquadrant(dot)com, Robert Haas <robertmhaas(at)gmail(dot)com>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: random() (was Re: New GUC to sample log queries) |
Date: | 2018-12-27 02:04:33 |
Message-ID: | 20181227020433.GH2106@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Dec 26, 2018 at 08:46:25PM -0500, Tom Lane wrote:
> 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?
Not much a fan of that for random() to be honest as we are talking
about 15 callers in the backend code and enforcing a call of in a
low-level library..
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-12-27 02:10:39 | Re: pgsql: Fix failure to check for open() or fsync() failures. |
Previous Message | Alexander Korotkov | 2018-12-27 01:59:11 | Re: GIN predicate locking slows down valgrind isolationtests tremendously |