From: | Martin Kalcher <martin(dot)kalcher(at)aboutsource(dot)net> |
---|---|
To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: [PATCH] Introduce array_shuffle() and array_sample() |
Date: | 2022-07-22 09:31:07 |
Message-ID: | 583b6409-df52-86d1-8c0a-ce8e74863ad7@aboutsource.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
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?
Attachment | Content-Type | Size |
---|---|---|
0001-Introduce-array_shuffle-and-array_sample.patch | text/x-patch | 16.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Dean Rasheed | 2022-07-22 11:04:06 | Re: [PATCH] Introduce array_shuffle() and array_sample() |
Previous Message | Dean Rasheed | 2022-07-22 07:59:20 | Re: [PATCH] Introduce array_shuffle() and array_sample() |
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Guo | 2022-07-22 09:33:24 | Re: Add proper planner support for ORDER BY / DISTINCT aggregates |
Previous Message | Matthias van de Meent | 2022-07-22 09:23:23 | Re: StrategyAM for IndexAMs |