Re: Unexpected results from CALL and AUTOCOMMIT=off
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Victor Yegorov <vyegorov@gmail.com>
Cc: Pierre Forstmann <pierre.forstmann@gmail.com>,
pgsql-general <pgsql-general@postgresql.org>
Date: 2024-06-03T19:28:10Z
Lists: pgsql-hackers, pgsql-general
Victor Yegorov <vyegorov@gmail.com> writes: > пн, 3 июн. 2024 г. в 20:40, Pierre Forstmann <pierre.forstmann@gmail.com>: >> If you remove stable from function declaration, it works as expected: > ... therefore I assume STABLE should work in this case. Well, it seems not > to. I agree that this looks like a bug, since your example shows that the same function works as-expected in an ordinary expression but not in a CALL. The dependency on AUTOCOMMIT (that is, being within an outer transaction block) seems even odder. I've not dug into it yet, but I suppose we're passing the wrong snapshot to the CALL arguments. A volatile function wouldn't use that snapshot, explaining Pierre's result. regards, tom lane
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix behavior of stable functions called from a CALL's argument list.
- a160e92779af 15.8 landed
- 2dc1deaea035 17.0 landed
- 1d4ea1376bf0 13.16 landed
- 0f7d1338c832 14.13 landed
- 0d18b8eb409c 16.4 landed
- 0be81dd71c85 12.20 landed