Re: problem with new autocommit config parameter and jdbc - Mailing list pgsql-hackers

From scott.marlowe
Subject Re: problem with new autocommit config parameter and jdbc
Date
Msg-id Pine.LNX.4.33.0209101145230.4854-100000@css120.ihs.com
Whole thread Raw
In response to Re: problem with new autocommit config parameter and jdbc  (Stephan Szabo <sszabo@megazone23.bigpanda.com>)
Responses Re: problem with new autocommit config parameter and jdbc  (Stephan Szabo <sszabo@megazone23.bigpanda.com>)
Re: problem with new autocommit config parameter and jdbc  (snpe <snpe@snpe.co.yu>)
List pgsql-hackers
On Tue, 10 Sep 2002, Stephan Szabo wrote:

> > > > > It starts a transaction, failes the first command and goes into the
> > > > > error has occurred in this transaction state.  Seems like reasonable
> > > > > behavior.
> > > >
> > > > Select command don't start transaction - it is not good
> > >
> > > I think you need more justification than "it is not good."  If I do a
> > > sequence of select statements in autocommit=false, I'd expect the same
> > > consistancy as if I'd done
> > > begin;
> > > select ...;
> > > select ...;
> > >
> > Ok.You start transaction explicit and this is ok.
> > But simple SELECT don't start transaction.
> 
> Actually someone post a bit from Date's book that implies it does.
> And, that's still not an justification, it's just a restating of same
> position. I don't see any reason why the two should be different from
> a data consistency standpoint, there might be one, but you haven't
> given any reasons.

What if it's a select for update?  IF that failed because of a timout on a 
lock, shouldn't the transaction fail?  Or a select into?  Either of those 
should make a transaction fail, and they're just selects.



pgsql-hackers by date:

Previous
From: Laurette Cisneros
Date:
Subject: Re:
Next
From: Tom Lane
Date:
Subject: Re: [JDBC] problem with new autocommit config parameter and jdbc