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

From Tom Lane
Subject Re: Why does "fetch last from cur" always cause error 55000 for non-scrollable cursor?
Date
Msg-id 1380649.1681418146@sss.pgh.pa.us
Whole thread Raw
In response to Why does "fetch last from cur" always cause error 55000 for non-scrollable cursor?  (Bryn Llewellyn <bryn@yugabyte.com>)
Responses Re: Why does "fetch last from cur" always cause error 55000 for non-scrollable cursor?
List pgsql-general
Bryn Llewellyn <bryn@yugabyte.com> writes:
> 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
rightresult). But it has to scroll backwards to do this. I'm guessing that the Version 11 behavior was regarded as a
bug—andwas fixed. When did the behavior change here? 

Probably here:

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

            regards, tom lane



pgsql-general by date:

Previous
From: Bryn Llewellyn
Date:
Subject: Why does "fetch last from cur" always cause error 55000 for non-scrollable cursor?
Next
From: Bryn Llewellyn
Date:
Subject: Re: Why does "fetch last from cur" always cause error 55000 for non-scrollable cursor?