Re: Resdhift's lack of cursors and PQsetSingleRowMode

From: Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com>
To: Marko Kreen <markokr(at)gmail(dot)com>
Cc: Ryan Kelly <rpkelly22(at)gmail(dot)com>, "psycopg(at)postgresql(dot)org" <psycopg(at)postgresql(dot)org>
Subject: Re: Resdhift's lack of cursors and PQsetSingleRowMode
Date: 2013-12-27 12:59:52
Message-ID: CA+mi_8bne7PeDD0dien1L2tjq3WKnTmJrUqCV01yEr+WLhm92Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: psycopg

On Thu, Dec 26, 2013 at 1:37 PM, Marko Kreen <markokr(at)gmail(dot)com> wrote:

> The single row mode is designed for following high-level API:
>
> curs = db.single-row-mode-cursor()
> curs.execute(sql)
> for row in curs.fetchall():
> process(row)

Because it's neither easy nor necessary to have a full-fledged cursor
object we could just have a new method on the cursor, returning an
iterable object responsible of all the state during the iteration:
something like:

for r in cur.execute_iter(query [, args]): # better name?
process(row)

Because in the DBAPI querying and retrieving is done with different
set of methods, I would have preferred something like:

cur.execute(query)
for row in cur.iter_single():
process(row)

but usually psycopg calls both PQexec and PQgetResult during execute()
so this interface wouldn't be straightforward to implement.

>> ISTM that in single row mode you can only get a single row per network

> No, libpq will still works with 8KB buffers over network.

Cool, no performance objection then, thank you for the clarification.

-- Daniele

In response to

Responses

Browse psycopg by date

  From Date Subject
Next Message Marko Kreen 2013-12-27 14:38:46 Re: Resdhift's lack of cursors and PQsetSingleRowMode
Previous Message Marko Kreen 2013-12-26 13:37:47 Re: Resdhift's lack of cursors and PQsetSingleRowMode