> > >>> 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