Search Postgresql Archives

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux