Re: problem with new autocommit config parameter and jdbc

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: snpe <snpe(at)snpe(dot)co(dot)yu>
Cc: "pgsql-jdbc(at)postgresql(dot)org" <pgsql-jdbc(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: problem with new autocommit config parameter and jdbc
Date: 2002-09-10 02:27:03
Message-ID: 15685.1031624823@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-jdbc

snpe <snpe(at)snpe(dot)co(dot)yu> writes:
> I'm use 'autocommit=false' and have problem with psql
> When any commnad is lost, then next commnad get error for transactions
> (simple select command).BTW

> snpe> select * from org_ba;
> ERROR: relation org_ba does not exists
> snpe> select * from org_ban;
> ERROR: current transactions is aborted, queries ignored until end of
> transaction block

Um, what's wrong with that?

It seems to me that an application that is using autocommit=off will
expect the first SELECT to start a transaction block. If the first
SELECT fails, then subsequent commands *should* fail until you commit
or rollback. Certainly if you did an explicit BEGIN before the first
SELECT, the above is what you'd get --- why should implicit BEGIN
work differently?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Christopher Kings-Lynne 2002-09-10 02:36:44 Re: Proposal: Solving the "Return proper affected tuple
Previous Message Bruce Momjian 2002-09-10 02:24:19 Re: Proposal: Solving the "Return proper effected tuple

Browse pgsql-jdbc by date

  From Date Subject
Next Message Curt Sampson 2002-09-10 02:51:21 Re: problem with new autocommit config parameter and jdbc
Previous Message Stephan Szabo 2002-09-10 02:16:47 Re: problem with new autocommit config parameter and jdbc