Sean Chittenden wrote:
> > 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
I think the above item is the issue. Everything is clear with
autocommit on. With autocommit off, COMMIT/ROLLBACK starts a
transaction, not BEGIN. BEGIN _can_ start a transaction, but it isn't
required:
COMMIT;
SET x=1;
SELECT ...;
SET x=2;
By making SET not start a transaction, x=2 is in a transaction, while
x=1 is not.
> *) 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
We have _zero_ cases right now where something happens outside a
transaction. In fact, everything is in a transaction. In fact, with
autocommit on you can't get out of a transaction. The idea of not
having SET start a transaction adds this pseudo state where we accept
SET but are not in a transaction until a non-SET occurs. That's the
strange part for me.
>
> 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
I think we left the standard when we made SET rollbackable. Maybe that
has to be reopened because if we did that, it would make perfect sense
because all SETs would be outside transactions.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073