Re: [PATCH] Introduce array_shuffle() and array_sample() - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH] Introduce array_shuffle() and array_sample()
Date
Msg-id 1064800.1658240423@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH] Introduce array_shuffle() and array_sample()  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [PATCH] Introduce array_shuffle() and array_sample()
Re: [PATCH] Introduce array_shuffle() and array_sample()
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Jul 19, 2022 at 9:53 AM Andrew Dunstan <andrew@dunslane.net> wrote:
>> Why not have an optional second parameter for array_shuffle that
>> indicates whether or not to flatten? e.g. array_shuffle(my_array,
>> flatten => true)

> IMHO, if we think that's something many people are going to want, it
> would be better to add an array_flatten() function, because that could
> be used for a variety of purposes, whereas an option to this function
> can only be used for this function.

Agreed.  Whether it's really needed, I dunno --- I don't recall the
issue having come up before.

After taking a second look through
https://www.postgresql.org/docs/current/functions-array.html
it seems like the things that treat arrays as flat even when they
are multi-D are just

* unnest(), which is more or less forced into that position by our
type system: it has to be anyarray returning anyelement, not
anyarray returning anyelement-or-anyarray-depending.

* array_to_string(), which maybe could have done it differently but
can reasonably be considered a variant of unnest().

* The containment/overlap operators, which are kind of their own
thing anyway.  Arguably they got this wrong, though I suppose it's
too late to rethink that.

Everything else either explicitly rejects more-than-one-D arrays
or does something that is compatible with thinking of them as
arrays-of-arrays.

So I withdraw my original position.  These functions should just
shuffle or select in the array's first dimension, preserving
subarrays.  Or else be lazy and reject more-than-one-D arrays;
but it's probably not that hard to handle them.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: [BUG] Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns
Next
From: Alvaro Herrera
Date:
Subject: Re: pgsql: Default to hidden visibility for extension libraries where possi