Re: BUG #17360: array_to_string should be immutable instead of stable
От | Tom Lane |
---|---|
Тема | Re: BUG #17360: array_to_string should be immutable instead of stable |
Дата | |
Msg-id | 2187793.1641826463@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #17360: array_to_string should be immutable instead of stable (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #17360: array_to_string should be immutable instead of stable
Re: BUG #17360: array_to_string should be immutable instead of stable |
Список | 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 по дате отправления: