[Pypgsql-devel] [ pypgsql-Bugs-747525 ] Commit Invalidating Client-Side Cursors

[SourceForge.net <no...@so...>]

Bugs item #747525, was opened at 2003-06-02 09:35
Message generated for change (Settings changed) made by ballie01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=747525&group_id=16528

Category: PgSQL
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Michael Owens (owensmk)
Assigned to: Billy G. Allie (ballie01)
Summary: Commit Invalidating Client-Side Cursors

Initial Comment:
This is a behavior issue. 
 
connection::commit() invalidates all cursors, even when 
noPostgresCursor = 1. Even though a transaction has completed, it 
seems uncessary to make data already stored in client-side cursors 
unreadable. As best I can tell, this behavior is not required by the specs 
either. 
 
I can understand why server-side cursors may have need of this, but it 
would be nice if client-side cursors could still be read. 

----------------------------------------------------------------------

Comment By: Billy G. Allie (ballie01)
Date: 2003-06-03 00:28

Message:
Logged In: YES 
user_id=8500

This is mandated by the way PostgreSQL works.  PostgreSQL
does not have cursors in the DB-API 2.0 sense.  At the libpq
API level, you execute a query on the connection, and
retrieve a result set containing all the data resulting from
the query.   PostgreSQL portals (i.e. what other DBs call
cursors) are backend contructs that allow the front end to
get data from the query in smaller units than just
retrieving all the rows at once.  In pyPgSQL, cursors are a
conglomeration of a connection object (needed to execute the
query and retrieve results) and a result object which has
all the results from the query (if portals are in use, then
the result object will not contain data until a FETCH SQL
command is executed).  Also note, that there can only be 1
active query on a connection at a time in PostgreSQL.  Also,
transaction are at the connection level, not the cursor
level which means that when a transaction is rolled back or
commited, then all cursors are reset to their inital state.
 The reason: portals only exist within a transaction, so
when a transaction is ended, all portals are closed and/or
invalidated, which means that the cursors using those
portals are reset.  This is done even if noPostgresCursor is
set to 1, so that the symatics of the cursor object in
pyPgSQL does not change depending on the setting of
noPostgresCursor.  If you need to keep the data returned by
a query, then you should use the fetchall() method and save
returned list of results.  The PgResultSet objects in the
list has the cursor.descriptor information available via the
PgResultSet.desriptor() method, so that information is not
"lost" when the cursor is closed or reused.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116528&aid=747525&group_id=16528