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 →
  1. Fix behavior of stable functions called from a CALL's argument list.