Fix misevaluation of STABLE parameters in CALL within plpgsql.
Before commit 84f5c2908, a STABLE function in a plpgsql CALL
statement's argument list would see an up-to-date snapshot,
because exec_stmt_call would push a new snapshot. I got rid of
that because the possibility of the snapshot disappearing within
COMMIT made it too hard to manage a snapshot across the CALL
statement. That's fine so far as the procedure itself goes,
but I forgot to think about the possibility of STABLE functions
within the CALL argument list. As things now stand, those'll
be executed with the Portal's snapshot as ActiveSnapshot,
keeping them from seeing updates more recent than Portal startup.
(VOLATILE functions don't have a problem because they take their
own snapshots; which indeed is also why the procedure itself
doesn't have a problem. There are no STABLE procedures.)
We can fix this by pushing a new snapshot transiently within
ExecuteCallStmt itself. Popping the snapshot before we get
into the procedure proper eliminates the management problem.
The possibly-useless extra snapshot-grab is slightly annoying,
but it's no worse than what happened before 84f5c2908.
Per bug #17199 from Alexander Nawratil. Back-patch to v11,
like the previous patch.
Discussion: https://postgr.es/m/17199-1ab2561f0d94af92@postgresql.org
Branch
------
REL_13_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/5f0a073cbbf8bdc276e570ffa006e762fc815e44
Modified Files
--------------
src/backend/commands/functioncmds.c | 22 +++++++++++++++++----
.../plpgsql/src/expected/plpgsql_transaction.out | 21 ++++++++++++++++++++
src/pl/plpgsql/src/sql/plpgsql_transaction.sql | 23 ++++++++++++++++++++++
3 files changed, 62 insertions(+), 4 deletions(-)