Horton

Re: [PATCH] Introduce array_shuffle() and array_sample()

Martin Kalcher <martin.kalcher@aboutsource.net>

View thread View on postgr.es
From: Martin Kalcher <martin.kalcher@aboutsource.net>
To: Dean Rasheed <dean.a.rasheed@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, Andrew Dunstan <andrew@dunslane.net>, John Naylor <john.naylor@enterprisedb.com>, Thomas Munro <thomas.munro@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-07-22T09:31:07Z
Lists: pgsql-hackers, pgsql-general

Attachments

Am 22.07.22 um 09:59 schrieb Dean Rasheed:>
> 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
> 

Hey Dean,

i came to the same conclusions and went with Option 1 (see patch). 
Mainly because most code in utils/adt is organized by type and this way 
it is clear, that this is a thin wrapper around pg_prng.

What do you think?

Commits

  1. Add array_sample() and array_shuffle() functions.

  2. Use a separate random seed for SQL random()/setseed() functions.