[DB-SIG] Re: [PyGreSQL] Version 3.0 PyGreSQL
Thu, 11 May 2000 17:48:03 -0400 (EDT)
>>>>> "BT" == Bill Tutt <email@example.com> writes:
BT> A Python int should be returned here, anything else is just
BT> plane silly.
I thought so. But the spec says nothing, so I wasn't sure.
BT> A DBI cursor doesn't have to map to a real
BT> database cursor. The existance of the cursor is just a way to
BT> allow a speration between a database connection, and individual
BT> statements on that connection, as some databases allow you do
BT> do. IIRC
It would be helpful to have a high-level mechanism to use real DB
cursors. I needed them for an application that was scanning a very
large table. Without a cursor provided by the DB, the pgsql library
copies the entire table out of the database; then the pgsqldb module
copies the entire table into a Python objects.
>> Does the DB spec have an author? Is this the right place to ask
>> questions? (I realize there are lots of reason for questions to
>> go unanswered.)
BT> MA Lemburg was the main driving force behind the v2.0 DBI spec.
BT> WRT the autocomit issue, ODBC also starts in autocommit mode as
BT> well. This is probably one fo those you like what you know
BT> questions. There are arguments on both sides of the issue.
It's fine for it to be a "know what you like" issue, except that there
isn't any standard way to put yourself in the other mode. There ought
to be an autocommit flag to the database connection and a
Are there any other issues outstanding that would lead to a third
version of the API?