Re: SET autocommit begins transaction?

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Rod Taylor <rbt(at)rbt(dot)ca>
Cc: Sean Chittenden <sean(at)chittenden(dot)org>, Thomas Lockhart <lockhart(at)fourpalms(dot)org>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: SET autocommit begins transaction?
Date: 2002-09-19 00:30:31
Message-ID: 200209190030.g8J0UVJ16851@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Rod Taylor wrote:
> > > 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.
>
> Of course, the reason they're rollbackable is:
>
> begin;
> create schema newschema;
> set search_path = newschema;
> rollback;
>
> create table junk; -- DOH!

And:

set statement_timeout = 20;
query_with_error;
set statement_timeout = 0;
COMMIT;

That will have to change in autocommit off to:

BEGIN;
SET statement_timeout = 20;
query_with_error;
SET statement_timeout = 0;
COMMIT;

I assume that BEGIN does start a transaction. With no BEGIN above, the
big problem is that it will work most of the time, but when/if the query
fails, they will find out they forgot the BEGIN.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Sean Chittenden 2002-09-19 00:32:52 Re: SET autocommit begins transaction?
Previous Message Rod Taylor 2002-09-19 00:25:29 Re: SET autocommit begins transaction?