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

Поиск
Список
Период
Сортировка
От Bryn Llewellyn
Тема Why does "fetch last from cur" always cause error 55000 for non-scrollable cursor?
Дата
Msg-id 3DDA11AC-718C-4B1A-BC98-7FC25DED0259@yugabyte.com
обсуждение исходный текст
Ответы Re: Why does "fetch last from cur" always cause error 55000 for non-scrollable cursor?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
I’m using Version 15.2. I did this test:

-- Test One
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 next  from cur;
  fetch first from cur;
rollback;

The first "fetch first" succeeds—presumably (given that the current position for a freshly-declared cursor is before the first row of the result set) because scrolling forwards takes you to the first row. And "fetch next" succeeds too. But the next "fetch first" fails with error 55000 ("cursor can only scan forward"). This makes perfect sense. It's not the spelling of the statement that matters; rather, it's the requested effect, given the cursor's current position.

I can imagine, therefore, that  "fetch last" might fail if the last row has already been fetched (for example with "fetch all") and you've fallen off the end of the result set.

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;

It needs only a forward scroll to get to the last row from this starting point.

I tried this as a sanity check:

-- Test Three
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 absolute 10 from cur;
  fetch next from cur;
rollback;

No errors. (But "fetch next" gets an empty result, as expected.) In other words, I can fetch the last row, when my current position is before it, by addressing it absolutely. But I can't do this by spelling it "last".

Am I missing something? Or might this be a bug?

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?

However, Test Two and Test Three behave the same in Version 11 as in Version 15. So my question about "fetch last" applies there too.

В списке pgsql-general по дате отправления:

Предыдущее
От: Evgeny Morozov
Дата:
Сообщение: Re: "PANIC: could not open critical system index 2662" - twice
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Why does "fetch last from cur" always cause error 55000 for non-scrollable cursor?