On Wed, 6 Sep 2006, Federico Di Gregorio wrote:
>> - server side cursors. Currently, most bindings for most databases have to
>> decide what to do after an cursor.execute() call - do they automatically
>> retrieve all the resulting rows in the client's memory, or do they
>> retrieve it row by row, pinging the server before every retrieval to get
>> more data (hey, not everybody using Oracle ;^). DB API has no support
>> for controlling this in a consistent fashion, even though Python has
>> solved the issue of dict.items() vs dict.iteritems() a long time ago.
>> The application writers should have a choice on how the cursors will
>> behave.
>
> Sure. psycopg 2 uses a little extension to the dbapi and adds to
> cursor() an extra parameter: "name". If a cursor is named then a server
> side cursor with that name is automatically generated (and destroyed at
> the end of the current transaction) else, if name is None, a normal
> cursor is created. Then fetchXXX() methods do the right thing without
> the need to introduce extra methods.
I did not go that rounte because of the potential confusion on named
parameters:
cu.execute("select * from products "
"where pname =:name and store =:store",
name = "foo", store = 37)
That - to me - feels much more natural, and makes it easy for the
execute() method to treat both *args and **kwargs simply as bind
parameters.
Cristian
--
Cristian Gafton
rPath, Inc.
_______________________________________________
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
