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