From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Kovács Péter <peter(dot)kovacs(at)chemaxon(dot)hu> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: TX semantics backward compatibility |
Date: | 2005-06-23 17:12:58 |
Message-ID: | 6411.1119546778@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
=?ISO-8859-1?Q?Kov=E1cs_P=E9ter?= <peter(dot)kovacs(at)chemaxon(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-06-23 17:30:56 | Re: plpgsql constraint checked data fails to restore |
Previous Message | Jim C. Nasby | 2005-06-23 17:06:24 | Re: [HACKERS] [PATCHES] Removing Kerberos 4 |