Re: SET autocommit begins transaction?

From: Sean Chittenden <sean(at)chittenden(dot)org>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Thomas Lockhart <lockhart(at)fourpalms(dot)org>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: SET autocommit begins transaction?
Date: 2002-09-18 23:32:46
Message-ID: 20020918233246.GK99484@perrin.int.nxad.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

> > > I am fine with special casing autocommit. Is that what you are
> > > suggesting?
> >
> > I think he means:
> >
> > Ex:
> > SET autocommit TO off;
> > SHOW autocommit;
> > ROLLBACK;
> > # warning about being outside of a transaction
> > BEGIN;
> > SET autocommit TO on;
> > SHOW autocommit; # shows on
> > ROLLBACK;
> > SHOW autocommit; # shows off
> >
> > Only have the SET's in a transaction/rollback-able if they're made
> > inside of a transaction, otherwise leave them as atomic changes. -sc
>
> But it seems so illogical that SET doesn't start a transaction, but
> if it is in a transaction, it is rolled back, and this doesn't help
> our statement_timeout example except to require that they do BEGIN
> to start the transaction even when autocommit is off.

Really? To me that makes perfect sense. Logic:

*) Only BEGIN starts a transaction
*) Database or session tunables are adjusted with SET
*) Only things that happen inside of a transaction are rollback-able
*) SET operations that happen outside of a transaction are atomic
changes that aren't subject to being rolled back

What about that doesn't make sense? Having SET begin a transaction
seems like a gross violation of POLS and likely to contradict the spec
and cause problems with many applications. -sc

--
Sean Chittenden

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Bruce Momjian 2002-09-18 23:40:45 Re: SET autocommit begins transaction?
Previous Message Bruce Momjian 2002-09-18 23:29:34 Re: SET autocommit begins transaction?