Re: TX semantics backward compatibility

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: TX semantics backward compatibility
Дата
Msg-id 6411.1119546778@sss.pgh.pa.us
обсуждение исходный текст
Ответ на TX semantics backward compatibility  (Kovács Péter <peter.kovacs@chemaxon.hu>)
Ответы Re: TX semantics backward compatibility  (Scott Marlowe <smarlowe@g2switchworks.com>)
Список 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 по дате отправления:

Предыдущее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: [HACKERS] [PATCHES] Removing Kerberos 4
Следующее
От: Tom Lane
Дата:
Сообщение: Re: plpgsql constraint checked data fails to restore