Re: [HACKERS] JDBC behaviour

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: [HACKERS] JDBC behaviour
Дата
Msg-id CAMsr+YFkcyjR_aDEQHXQ2_tb_mxRe7y-_tuhdNi25hYs0ztKpA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] JDBC behaviour  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [HACKERS] JDBC behaviour  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-jdbc
On 23 February 2016 at 21:34, Robert Haas <robertmhaas@gmail.com> wrote:
On Sat, Feb 20, 2016 at 4:14 PM, Craig Ringer <craig@2ndquadrant.com> wrote:
>> currently PostgreSQL::"set autocommit to FALSE ( not supported )
>
> This also does not make any sense.
>
> PgJDBC does support turning autocommit off. So I don't know in what way it's
> "not supported".

I believe Sridhar is imagining that someday "set autocommit to false"
might be a command that the server would understand.

... I guess. Yeah.

Oracle's SQL*Plus has the concept of turning autocommit off, but I suspect that's client-side behaviour.


I can't really imagine how it'd make sense on the server side, given how the protocol works etc. Nor is it necessary since the desired behaviour is entirely controlled on the client side.

We could have a server mode that did silent, automatic savepoints and rolled back to a savepoint automatically on ERROR. That wouldn't be the same as autocommit, but appears to be what Sridhar actually needs. There's even the remotest chance someone could come up with a patch that might be acceptable, but I don't know of anyone who'd want to do it when it can be done well enough client side.

I think Sridhar is confusing autocommit with other DBMSes behaviour of automatically rolling back failed statements without affecting the rest of the transaction. These are not the same thing.

--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

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

Предыдущее
От: Craig Ringer
Дата:
Сообщение: Re: JDBC behaviour
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] JDBC behaviour