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