[DB-SIG] New take on PostgreSQL bindings for Python

[Cristian Gafton]

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.