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: pgsql-bugs(at)postgresql(dot)org
Subject: Re: SET autocommit begins transaction?
Date: 2002-09-18 21:57:34
Message-ID: 20020918215734.GA6389@perrin.int.nxad.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

> > > Well there is discussion on whether a SET with autocommit off should
> > > start a transaction if it is the first command. Right now it does, and
> > > clearly you have a case where it acts strangely.
> >
> > Problem is that through various DB APIs such as DBI, you can't
> > garuntee to the user doing development that that it's the 1st command
> > that they're performing.
>
> OK, but why does my suggestion not work:
>
> SET autocommit = ON;
> COMMIT;

Hrm... if I changed the DBI layer for Ruby to have:

db['AutoCommit'] = true

use 'SET autocommit = ON; COMMIT;' I think I'd be breaking tons of
applications where they wouldn't be expecting the commit.

> Yep, we don't like special cases and that is why we avoided it. Just
> explaining the special case causes all sorts of confusion, as you have
> seen from my emails.

Yup, exceptions aren't elegant, but since there's only one way of
SET'ting variables and this one is very key to transactions, I don't
know of another way than possibly creating a parallel command to SET
that'd avoid this rollback/commit silliness... but that seems like a
step backwards and is why I'd think an exception would be good. -sc

--
Sean Chittenden

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Bruce Momjian 2002-09-18 21:59:14 Re: SET autocommit begins transaction?
Previous Message Bruce Momjian 2002-09-18 21:54:19 Re: SET autocommit begins transaction?