> 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?
(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 ?
But it is possible to check transaction status from another part of pgAdmin or
even make the window with result set modal ?
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
// Dmitriy.
