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