Re: Rollback on close [Was: Fwd: [DB-SIG] conn.close() idempotence]

On Wed, Oct 19, 2011 at 6:13 PM, Marko Kreen <markokr(at)gmail(dot)com> wrote:
> On Wed, Oct 19, 2011 at 3:59 PM, Daniele Varrazzo
> <daniele(dot)varrazzo(at)gmail(dot)com> wrote:
>> On Wed, Oct 19, 2011 at 1:12 PM, Marko Kreen <markokr(at)gmail(dot)com> wrote:
>> Well, you know the middleware much better than me: I was assuming that
>> if pgpool discards connection returned idle in transaction to the pool
>> you have very strong reasons :) I just want to optimize the
>> communication between the driver and the middleware: what do you think
>> the "protocol" between psycopg and pgpool should be?
>
> Thats easy - do not rollback.

Let's clarify that further - DB-API *MUST* say that .close()
[and also .__del__()] will rollback. Eg - imagine
driver accessing .dbf / .csv files directly.

But there is no good reason to require communication
with backend if the backend will rollback anyway
on connection close.

DB-API 2.0:
.close()

Close the connection now (rather than whenever __del__ is
called). The connection will be unusable from this point
forward; an Error (or subclass) exception will be raised
if any operation is attempted with the connection. The
same applies to all cursor objects trying to use the
connection. Note that closing a connection without
committing the changes first will cause an implicit
rollback to be performed.

From my reading, .close() and .__del__() *are* equivalent,
and no explicit communication is required, if the backend
will rollback anyway on connection close.

Not that I'm against breaking DB-API if the wording is insane,
but the wording seems to direct towards sane behaviour.

--
marko