On Thu, 2005-06-23 at 12:12, Tom Lane wrote:
> =?ISO-8859-1?Q?Kov=E1cs_P=E9ter?= <peter.kovacs@chemaxon.hu> writes:
> > The problem is with the kind of code
> > where we test the existence of a table in a transaction with:
>
> > select count(*) from doesitexist where 1 = 2;
>
> AFAIK the behavior of that has not changed since forever: if doesitexist
> doesn't exist you'll get an error, and unless you take steps like
> establishing a savepoint then the error aborts your transaction.
> If you think the behavior has changed you will have to give a complete
> example.
>
> > Of course, we rely on we-do-not-exactly-now-how-many places on a
> > transaction still being usable after a (read-only) statement level error.
>
> PG has *never* behaved that way.
>
> > Or may something have changed in the client driver we use (JDBC)?
>
> Certainly many things have changed in both the server and JDBC since
> 7.2. You might try the combinations of older-JDBC-newer-server and
> older-server-newer-JDBC to see if you can narrow down which component
> is causing you problems. If it seems to be JDBC, the pgsql-jdbc list
> is a better place to ask about it.
What versions of postgresql supported the abortive non-autocommit mode
that caused so many problems, could it be that 7.2 did, and it was on
for this fellow?