Re: problem with new autocommit config parameter and jdbc - Mailing list pgsql-hackers

From Curt Sampson
Subject Re: problem with new autocommit config parameter and jdbc
Date
Msg-id Pine.NEB.4.44.0209111041500.23252-100000@angelic.cynic.net
Whole thread Raw
In response to Re: problem with new autocommit config parameter and jdbc  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: problem with new autocommit config parameter and jdbc  (Rod Taylor <rbt@rbt.ca>)
List 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


pgsql-hackers by date:

Previous
From: Curt Sampson
Date:
Subject: Re: Optimization levels when compiling PostgreSQL...
Next
From: Curt Sampson
Date:
Subject: Re: Script to compute random page cost