We don't enforce NO SCROLL cursor restrictions
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@lists.postgresql.org
Date: 2021-09-09T17:10:35Z
Lists: pgsql-hackers
We don't actually prevent you from scrolling a NO SCROLL cursor:
regression=# begin;
BEGIN
regression=*# declare c no scroll cursor for select * from int8_tbl;
DECLARE CURSOR
regression=*# fetch all from c;
q1 | q2
------------------+-------------------
123 | 456
123 | 4567890123456789
4567890123456789 | 123
4567890123456789 | 4567890123456789
4567890123456789 | -4567890123456789
(5 rows)
regression=*# fetch absolute 2 from c;
q1 | q2
-----+------------------
123 | 4567890123456789
(1 row)
There are probably specific cases where you do get an error,
but we don't have a blanket you-can't-do-that check. Should we?
The reason this came to mind is that while poking at [1]
I noticed that commit ba2c6d6ce has created some user-visible
anomalies for non-scrollable cursors WITH HOLD. If you advance
the cursor a bit, commit, and then try to scroll the cursor,
it will work but the part of the output that you advanced over
will be missing. I think we should probably throw an error
to prevent that from being visible. I'm worried though that
putting in a generic prohibition may break applications that
used to get away with this kind of thing.
regards, tom lane
[1] https://www.postgresql.org/message-id/CAPV2KRjd%3DErgVGbvO2Ty20tKTEZZr6cYsYLxgN_W3eAo9pf5sw%40mail.gmail.com
Commits
-
Fix some anomalies with NO SCROLL cursors.
- fa5d0415f10f 13.5 landed
- d844cd75a676 14.0 landed
- c1b7a6c27312 15.0 landed
- ba408fc960b6 12.9 landed
- 9ea8d3d24a9f 11.14 landed
-
Avoid misbehavior when persisting a non-stable cursor.
- ba2c6d6cec00 14.0 cited