Re: [JDBC] problem with new autocommit config parameter and jdbc

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [JDBC] problem with new autocommit config parameter and jdbc
Дата
Msg-id 21050.1031683534@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [JDBC] problem with new autocommit config parameter and  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: [JDBC] problem with new autocommit config parameter and  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> Does anyone see any cases where it's important for SET to start
>> a transaction?  (Of course, if you are already *in* a transaction,
>> the SET will be part of that transaction.  The question is whether
>> we want SET to trigger an implicit BEGIN or not.)

> Uh, well, because we now have SET's rollback in an aborted transaction,
> there is an issue of whether the SET is part of the transaction or not.
> Seems it has to be for consistency with our rollback behavior.

Yeah, it must be part of the transaction unless we want to reopen the
SET-rollback can of worms (which I surely don't want to).

However, a SET issued outside any pre-existing transaction block could
form a self-contained transaction without any logical difficulty, even
in autocommit-off mode.  The question is whether that's more or less
convenient, or standards-conforming, than what we have.

An alternative that I'd really rather not consider is making SET's
behavior dependent on exactly which variable is being set ...

            regards, tom lane

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "scott.marlowe"
Дата:
Сообщение: Re: problem with new autocommit config parameter and jdbc
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [JDBC] problem with new autocommit config parameter and