On Thu, Apr 17, 2008 at 04:06:57AM -0700, Paul Boddie wrote:
> One caveat: psycopg2 doesn't (or didn't) use cursors in a transparent
> fashion like pyPgSQL does. If you're traversing potentially large data
> sets, this will mean that psycopg2 will download all the result data
> into the client process unless you start introducing explicit DECLARE
> CURSOR statements in all the right places. Although this might not be
> an issue if you're determined to only support PostgreSQL and psycopg2,
> it's worth noting that the behaviour is somewhat counter-intuitive
> from the perspective of people with experience of other database
> systems: attempting to fetch a single row (or a limited number of
> rows) may cause you to discover that the client has acquired all of
> them
If one wants to operate on one/a range of row(s) but the
code fetches "all" rows (for various values of all) then I'd
suspect there's something missing in the SQL statement, say,
a LIMIT or appropriate WHERE conditions - regardless of
whether a cursor is used or not.
If you refer to whether server-side cursors are used one
must explicitly request them from psycopg2 by using the
"name" argument to the connection.Cursor() call. Combine
that with a Python generator and one should end up with
truly on-demand single-row fetching.
Unfortunately, I am not entirely sure how and when psycopg2
uses (database) cursors when no name argument is supplied.
IMO the cursor concept of the DB-API is broken anyhow -
everything is forced to go through a (DB-API) cursor no
matter whether a database-side cursor would be wanted or not
and there's no provision for controlling the latter via the
API itself.
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
