Re: problem with new autocommit config parameter and jdbc

Curt Sampson <cjs@cynic.net>

From: Curt Sampson <cjs@cynic.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: snpe <snpe@snpe.co.yu>, "pgsql-jdbc@postgresql.org" <pgsql-jdbc@postgresql.org>, <pgsql-hackers@postgresql.org>
Date: 2002-09-11T01:44:39Z
Lists: pgsql-hackers
On Tue, 10 Sep 2002, Tom Lane wrote:

> As of CVS tip, SET commands *do* initiate transactions
> if you have autocommit off.  By your reading of Date, this is not
> spec compliant for certain SET variables: a SET not already within
> a transaction should not start a transaction block, at least for the
> variables mentioned above.  It occurs to me that it'd be reasonable
> to make it act that way for all SET variables.

I agree. SET variables are normally related to the behaviour of a
session, not information stored in the database. And your autocommit
example shows why having them start a transaction is a problem.

But there were some issues with rolling back and SET commands,
weren't there? I remember a long discussion about this that I'm
not sure I want to go back to. :-)

> >     Nor, of course, are the nonexecutable statements DECLARE CURSOR,
> >     DECLAR LOCAL TEMPORARY TABLE, BEGIN DECLARE SECTION, SEND DECLARE
> >     SECTIONS, and WHENEVER.
>
> Hmm.  I think the spec's notion of DECLARE must be different from ours.
> Our implementation of DECLARE CURSOR both declares and opens the cursor,
> and as such it *must* be transaction-initiating; else it's useless.

Well, I'm not going to go chase it down right now, but ISTR that
DECLAREing a cursor just allocates a variable name or the storage for it
or something like that; it doesn't actually create an active cursor.

cjs
-- 
Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974   http://www.netbsd.org
    Don't you know, in this new Dark Age, we're all light.  --XTC