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