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

> tgl(at)sss(dot)pgh(dot)pa(dot)us wrote:
>
>> bryn(at)yugabyte(dot)com <mailto:bryn(at)yugabyte(dot)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.