We don't enforce NO SCROLL cursor restrictions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: We don't enforce NO SCROLL cursor restrictions
Date: 2021-09-09 17:10:35
Message-ID: 3712911.1631207435@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Dilger 2021-09-09 17:42:11 Re: [Patch] ALTER SYSTEM READ ONLY
Previous Message Fujii Masao 2021-09-09 16:30:34 Re: Avoid stuck of pbgench due to skipped transactions