From: | snpe <snpe(at)snpe(dot)co(dot)yu> |
---|---|
To: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
Cc: | "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>, Rod Taylor <rbt(at)rbt(dot)ca>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: problem with new autocommit config parameter and jdbc |
Date: | 2002-09-11 13:02:23 |
Message-ID: | 200209111502.23968.snpe@snpe.co.yu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-jdbc |
On Wednesday 11 September 2002 03:14 am, Stephan Szabo wrote:
> 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.
>
If decision (transaction or not) is after parser (before execute) this isn't
problem.
I don't know when postgresql make decision, but that is best after parser.
I parser find error simple return error and nothing happen
> > 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.
>
Question ?
All select in one transaction return same data - no matter if any change and
commit data ?
> 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.
Can I find sql99 spec anywhere ?
Thanks
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Szabo | 2002-09-11 13:06:57 | Re: problem with new autocommit config parameter and jdbc |
Previous Message | snpe | 2002-09-11 12:56:09 | Re: problem with new autocommit config parameter and jdbc |
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Szabo | 2002-09-11 13:06:57 | Re: problem with new autocommit config parameter and jdbc |
Previous Message | snpe | 2002-09-11 12:56:09 | Re: problem with new autocommit config parameter and jdbc |