Re: Why does "fetch last from cur" always cause error 55000 for non-scrollable cursor? - Mailing list pgsql-general

From Bryn Llewellyn
Subject Re: Why does "fetch last from cur" always cause error 55000 for non-scrollable cursor?
Date
Msg-id 90AC43E5-6C39-4CF7-B037-EE7C7F4884BB@yugabyte.com
Whole thread Raw
In response to Re: Why does "fetch last from cur" always cause error 55000 for non-scrollable cursor?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
tgl@sss.pgh.pa.us wrote:


But why does "fetch last" fail here:

-- Test Two
start transaction;
 declare cur no scroll cursor without hold for
 select g.val as k, g.val*100 as v
 from generate_series(1, 10) as g(val)
 order by g.val;

 fetch first from cur;
 fetch last  from cur;
rollback;

FETCH LAST is implemented as "run forward to the end, then back up one". You could imagine adding more infrastructure to allow doing it without backup, but it'd be complicated (not least because the cursor's ending position would be subtly wrong).

Finally, I tried the same tests in PG 11.19. There, in Test One, the second "fetch first" succeeds (and gets the right result). But it has to scroll backwards to do this. I'm guessing that the Version 11 behavior was regarded as a bug—and was fixed. When did the behavior change here?

Probably here:

git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=c1b7a6c27

Thanks for the quick response, Tom. "Could be done—but not cost-effective effort" works for me.

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Why does "fetch last from cur" always cause error 55000 for non-scrollable cursor?
Next
From: Laurenz Albe
Date:
Subject: Re: "PANIC: could not open critical system index 2662" - twice