From: Tom Lane <tgl@sss.pgh.pa.us>
To: gergely.czuczy@harmless.hu
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17360: array_to_string should be immutable instead of stable
In-reply-to: <17360-a50d754b72a97cad@postgresql.org>
References: <17360-a50d754b72a97cad@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Mon, 10 Jan 2022 10:47:26 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2187792.1641826463.1@sss.pgh.pa.us>
Date: Mon, 10 Jan 2022 09:54:23 -0500
Message-ID: <2187793.1641826463@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2187793.1641826463%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> The array_to_string function should have a volatility of immutable,

Nope.  It invokes an arbitrary datatype I/O function,
which might only be stable.  As an example:

regression=# begin;
BEGIN
regression=*# select array_to_string(array[now()], ',');
        array_to_string        
-------------------------------
 2022-01-10 09:47:06.605304-05
(1 row)

regression=*# set timezone to UTC;
SET
regression=*# select array_to_string(array[now()], ',');
        array_to_string        
-------------------------------
 2022-01-10 14:47:06.605304+00
(1 row)

Actually, in principle somebody could make a datatype
whose output function is volatile.  It's not clear
what the use-case is, though, so we've established a
project policy that code that invokes some arbitrary
I/O function may assume that function is at least stable.
Thus, array_to_string() is marked stable, and likewise
for some other polymorphic functions such as format().

Ideally, perhaps, we'd determine the volatility level of
polymorphic functions like array_to_string() based on the
actual input data types --- but it's hard to see how to do
that.

			regards, tom lane