Re: TX semantics backward compatibility - Mailing list pgsql-general

From Tom Lane
Subject Re: TX semantics backward compatibility
Date
Msg-id 6411.1119546778@sss.pgh.pa.us
Whole thread Raw
In response to TX semantics backward compatibility  (Kovács Péter <peter.kovacs@chemaxon.hu>)
Responses Re: TX semantics backward compatibility
List pgsql-general
=?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.

            regards, tom lane

pgsql-general by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: [HACKERS] [PATCHES] Removing Kerberos 4
Next
From: Tom Lane
Date:
Subject: Re: plpgsql constraint checked data fails to restore