[DB-SIG] Re: [PyGreSQL] Version 3.0 PyGreSQL

Greg Stein gstein@lyra.org
Thu, 11 May 2000 15:00:12 -0700 (PDT)


On Thu, 11 May 2000, Jeremy Hylton wrote:
>...
>   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.

Um... there is. The DBAPI allows for real DB cursors. Did you mean
something else?

>  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.

Poor implementation. The DBAPI is designed around true cursors, so pgsqldb
should use that design.

I believe the problem may be that pgsqldb was designed against an older
PostgreSQL, which didn't have cursors.

>   >> 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
> beginTransaction method.

The specification states that autocommit must be OFF by DEFAULT. That is a
solid definition, and all DBAPI-compatible modules obey that. Bill was a
bit misleading there :-)

Turning autocommit on/off is performed in a module-specific manner. It is
not part of the DBAPI spec.

beginTransaction is implied by issuing a statement. The transaction ends
when you call .commit()

> Are there any other issues outstanding that would lead to a third
> version of the API?

Not really. A few here and there. Dunno if anybody has been collecting
them.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/