> > >>> Does turnning autocommit off enter you into a transaction? Am I > > >>> smoking something or does that seems broken? > > > > > Tom, do you want to special case autocommit? I think that would be OK. > > > > No, I don't like that either ... in general I do not think SET's > > behavior should vary depending on which variable is being set. > > Yep, this is where we got lost before. You don't want to special case > SET variables, but you _do_ want to special case SET at the start of a > transaction. Did you see my timeout example? How is that supposed to > be handled cleanly? > > SET statement_timeout = 20; > query generates error; > SET statement_timeout = 0; > COMMIT; > > If the first SET doesn't start a transaction and isn't part of the > transaction, I don't see how to do this. Maybe: > > BEGIN; > SET statement_timeout = 20; > query generates error; > SET statement_timeout = 0; > COMMIT; > > So then you have to train people that their initial SET isn't part of > the transaction, though the later one is. Yuck. > > I think we diverted from the spec when we went with making SET > rollbackable and now we are seeing the problems caused. > > Why exactly did you want the initial SET to not be part of the > transaction?
Is having an exception all that bad? What other tunables should be outside of the reach of transactions? Maybe an exception should be applied to a class of SET tunables. -sc -- Sean Chittenden ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
