> t...@sss.pgh.pa.us wrote: > >> b...@yugabyte.com <mailto:b...@yugabyte.com> 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.
