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 <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org