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

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

> The core of the difficulty is that although timestamptz_out
> is getting called, that's nowhere visible in the parse tree.
> I suppose we could decide that it's illegal to allow
> array_to_string() or format() to exist, but I don't think
> anybody will like that answer.
>

Yeah. The user expectation (and arguably architectural ideal) that the
output representation of data types is immutable being violated is the
bigger issue here but one that we are basically stuck with. As you note
below, however, since real complaints mostly manifest in polymorphic
situations, coming up with a solution at that scope, one that makes
function volatility a planning time property instead of a create function
time one, makes the most sense. Since the function is being defined for
planning time type resolution, extending that to volatility is internally
consistent.

David J.