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
|
Список | 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 по дате отправления: