From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | gergely(dot)czuczy(at)harmless(dot)hu |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #17360: array_to_string should be immutable instead of stable |
Date: | 2022-01-10 14:54:23 |
Message-ID: | 2187793.1641826463@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
PG Bug reporting form <noreply(at)postgresql(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Gergely Czuczy | 2022-01-10 15:01:56 | Re: BUG #17360: array_to_string should be immutable instead of stable |
Previous Message | PG Bug reporting form | 2022-01-10 10:47:26 | BUG #17360: array_to_string should be immutable instead of stable |