Force NO SCROLL for plpgsql's implicit cursors.
authorTom Lane
Tue, 8 Jun 2021 22:40:06 +0000 (18:40 -0400)
committerTom Lane
Tue, 8 Jun 2021 22:40:06 +0000 (18:40 -0400)
commitc5b28184132d30ce7f77b24b0e7f302a8f37f407
treed99337b60645232e3d19d7a939365326b62a77e5
parentc1fd756fd23f60fcac120c9cd36de2921144e3bd
Force NO SCROLL for plpgsql's implicit cursors.

Further thought about bug #17050 suggests that it's a good idea
to use CURSOR_OPT_NO_SCROLL for the implicit cursor opened by
a plpgsql FOR-over-query loop.  This ensures that, if somebody
commits inside the loop, PersistHoldablePortal won't try to
rewind and re-read the cursor.  While we'd have selected NO_SCROLL
anyway if FOR UPDATE/SHARE appears in the query, there are other
hazards with volatile functions; and in any case, it's silly to
expend effort storing rows that we know for certain won't be needed.

(While here, improve the comment in exec_run_select, which was a bit
confused about the rationale for when we can use parallel mode.
Cursor operations aren't a hazard for nameless portals.)

This wasn't an issue until v11, which introduced the possibility
of persisting such cursors.  Hence, back-patch to v11.

Per bug #17050 from Алексей Булгаков.

Discussion: https://postgr.es/m/17050-f77aa827dc85247c@postgresql.org
src/pl/plpgsql/src/pl_exec.c