Re: problem with new autocommit config parameter and jdbc
От | Curt Sampson |
---|---|
Тема | Re: problem with new autocommit config parameter and jdbc |
Дата | |
Msg-id | Pine.NEB.4.44.0209111041500.23252-100000@angelic.cynic.net обсуждение исходный текст |
Ответ на | Re: problem with new autocommit config parameter and jdbc (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: problem with new autocommit config parameter and jdbc
|
Список | 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 по дате отправления: