> I've seen that behaviour before in similar applications, but it had a > major downside: the number of rows returned was not known in advance > of scrolling down to the last one. So you couldn't visualise the size > of the record set based on the size and relative position of the > scrollbar.
Why not MOVE cursor to the end, then get number of ROWS (PQcmdTuples) affected by the MOVE command, and finally MOVE the first tuple to determine the number of returned rows?
That is basically how it works (MVC), albeit without using cursors; for both the reason you state and because part of the point of the tool is to tune queries and using cursors to do that completely messes up any timings we might get.
Do you mean that cursors (regular, not holdable) live only inside a transactions? But it is possible to check transaction status from another part of pgAdmin or even make the window with result set modal ?
