Hello,
Thanks for explaining Tom, I wasn't aware these things on the internals.
Wouldn't it possible to add polymorphs for immutable types, like
func(text[]), func(int[]), etc, mark those immutable, and keep the
generic for all the other not-explicitly-dealt-with types as stable?
Again, I don't really know the implementation details here, so it's just
my tuppence.
Thanks again for explaining it.
Regards,
Gergely
On 2022. 01. 10. 15:54, Tom Lane wrote:
> 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
