Re: BUG #17360: array_to_string should be immutable instead of stable

On Mon, Jan 10, 2022 at 7:54 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> 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()], ',');
>

That feels wrong. It's not like we are passing the "now()" function to the
function and invoking it later. So far as array_to_string is concerned it
is being given a literal value.

By your argument, isfinite(timestamp) should be stable but it is immutable
(it's the first example I stumbled across, I suspect there are quite a few
more I could contrive).

select isfinite(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)
>
> [...]

> 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.
>

In short, that doesn't make sense. The volatility level of a function is
only determined by the implementation code of said function. The function
invoking expression volatility level depends upon the most volatile
behavior of all functions used in the expression. That we should be doing
if we aren't already.

David J.