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

From Stephan Szabo
Subject Re: problem with new autocommit config parameter and jdbc
Date
Msg-id 20020910175248.U30015-100000@megazone23.bigpanda.com
Whole thread Raw
In response to Re: problem with new autocommit config parameter and jdbc  (snpe <snpe@snpe.co.yu>)
Responses Re: problem with new autocommit config parameter and jdbc  (snpe <snpe@snpe.co.yu>)
List pgsql-hackers
On Wed, 11 Sep 2002, snpe wrote:

> On Wednesday 11 September 2002 02:09 am, Stephan Szabo wrote:
> > On Wed, 11 Sep 2002, snpe wrote:
> > > yes, we're going around in circles.
> > >
> > > Ok.I agreed (I think because Oracle do different)
> > > Transaction start
> > > I type invalid command
> > > I correct command
> > > I get error
> > >
> > > Why.If is it transactin, why I get error
> > > I want continue.
> > > I am see this error with JDeveloper (work with Oracle, DB2 an SQL Server)
> >
> > Right, that's a separate issue (I alluded to it earlier, but wasn't sure
> > that's what you were interested in).  PostgreSQL treats all errors as
> > unrecoverable.  It may be a little loose about immediately rolling back
> > due to the fact that historically autocommit was on and it seemed better
> > to not go into autocommit mode after the error.
> >
> > I doubt that 7.3 is going to change that behavior, but a case might be
> > made that when autocommit is off the error immediately causes a rollback
> > and new transaction will start upon the next statement (that would
> > normally start a transaction).
> >
>
> Why rollback.This is error (typing error).Nothing happen.

Postgresql currently has no real notion of a recoverable error.
In the case of the error you had, probably nothing bad would happen
if it continued, but what if that was a unique constraint violation?
Continuing would currently probably let you see the table in an
invalid state.

> I think that we need clear set : what is start transaction ?
> I think that transaction start with change data in database
> (what don't change data this start not transaction.
> Oracle dot this and I think that is correct))

I disagree because I think that two serializable select statements
in autocommit=off (without a commit or rollback of course) should
see the same snapshot.

I'm trying to find something either way in a pdf copy of sql99.
The multiple row select has gotten hidden somewhere, so it's possible
that it's not, but all of opening a cursor, fetching from a cursor
and the single row select syntax are labeled as transaction initiating.



pgsql-hackers by date:

Previous
From: snpe
Date:
Subject: Re: problem with new autocommit config parameter and jdbc
Next
From: Curt Sampson
Date:
Subject: Re: Optimization levels when compiling PostgreSQL...