Re: Support getrandom() for pg_strong_random() source - Mailing list pgsql-hackers

On Tue, Sep 30, 2025 at 12:44 AM Daniel Gustafsson <daniel@yesql.se> wrote:
> What if we instead expand the API to provide pg_random (or pg_fast_random)
> which can be a selectable implementation, and pg_strong_random is left as today
> a compile time selection?

I like the idea of tiering it, but I'm not sure how to communicate to
developers when they should prefer pg_strong_random over
pg_fast_random over pg_prng (which is hopefully faster than
pg_fast_random!).

Is the dividing line really strong vs fast, or is it compliance vs
noncompliance? Because I have a feeling that for some users, the
"fast" alternative that is chosen will be stronger than the "strong"
version they are mandated to select.

Are there any use cases other than UUID that want CSPRNG guarantees
without needing CSPRNG security?

--Jacob