Re: BUG #17360: array_to_string should be immutable instead of stable - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #17360: array_to_string should be immutable instead of stable
Date
Msg-id 2187793.1641826463@sss.pgh.pa.us
Whole thread Raw
In response to BUG #17360: array_to_string should be immutable instead of stable  (PG Bug reporting form <noreply@postgresql.org>)
Responses Re: BUG #17360: array_to_string should be immutable instead of stable
Re: BUG #17360: array_to_string should be immutable instead of stable
List pgsql-bugs
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



pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #17360: array_to_string should be immutable instead of stable
Next
From: Gergely Czuczy
Date:
Subject: Re: BUG #17360: array_to_string should be immutable instead of stable