On Thu, 21 Jul 2022 at 16:43, Martin Kalcher
<martin.kalcher@aboutsource.net> wrote:
>
> Am 21.07.22 um 14:25 schrieb Dean Rasheed:
> >
> > I'm inclined to say that we want a new pg_global_prng_user_state that
> > is updated by setseed(), and used by random(), array_shuffle(),
> > array_sample(), and any other user-facing random functions we add
> > later.
> >
>
> I like the idea. How would you organize the code? I imagine some sort of
> user prng that is encapsulated in something like utils/adt/random.c and
> is guaranteed to always be seeded.
>
Something like that, perhaps. I can see 2 ways it could go:
Option 1:
Keep random.c small
- Responsible for initialisation of the user prng on demand
- Expose the user prng state to other code like float.c and arrayfuncs.c
Option 2:
Move all random functions wanting to use the user prng to random.c
- Starting with drandom() and setseed()
- Then, array_shuffle() and array_sample()
- Later, any new SQL-callable random functions we might add
- Keep the user prng state local to random.c
Option 2 seems quite appealing, because it keeps all SQL-callable
random functions together in one place, and keeps the state local,
making it easier to keep track of which functions are using it.
Code like the Fisher-Yates algorithm is more to do with random than it
is to do with arrays, so putting it in random.c seems to make more
sense.
It's possible that some hypothetical random function might need access
to type-specific internals. For example, if we wanted to add a
function to return a random numeric, it would probably have to go in
numeric.c, but that could be solved by having random.c call numeric.c,
passing it the prng state.
Regards,
Dean