Re: Support getrandom() for pg_strong_random() source

On Mon, Oct 06, 2025 at 11:41:07AM -0700, Jacob Champion wrote:
> On Tue, Sep 30, 2025 at 12:44 AM Daniel Gustafsson <daniel(at)yesql(dot)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!).

Separating that at API level sounds like a good alternative, yes.

> 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.

Yeah.. I'm not sure that it is our job to draw a strict line, either.
We are labelled as database specialists. When it comes to
cryptography, I cannot say for all the others but I'm very confident
in the fact that I'm bad at it.

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

One option would be to just document at the top of the API added the
use case that would be in the tree with the new "fast" API (aka the
UUID case) with a slight mention of the RFCs? It seems like in any
case we should be very careful when choosing "fast" call, while the
"strong" one is good option anyway if you just don't know which one
you should choose when adding a new caller that wants random bytes.
--
Michael