Re: Surprising behaviour of \set AUTOCOMMIT ON
| От | Pavel Stehule |
|---|---|
| Тема | Re: Surprising behaviour of \set AUTOCOMMIT ON |
| Дата | |
| Msg-id | CAFj8pRAwXSYYL7rTOeXHufP6_YssGFJYVX=AgVp7YYrinSSB1Q@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Surprising behaviour of \set AUTOCOMMIT ON (Amit Kapila <amit.kapila16@gmail.com>) |
| Список | pgsql-hackers |
2016-08-06 7:29 GMT+02:00 Amit Kapila <amit.kapila16@gmail.com>:
On Thu, Aug 4, 2016 at 7:46 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> 2016-08-04 15:37 GMT+02:00 Amit Kapila <amit.kapila16@gmail.com>:
>>
>> > I dislike automatic commit or rollback here.
>> >
>>
>> What problem you see with it, if we do so and may be mention the same
>> in docs as well. Anyway, I think we should make the behaviour of both
>> ecpg and psql same.
>
>
> Implicit COMMIT can be dangerous
>
Not, when user has specifically requested for autocommit mode as 'on'.
I think here what would be more meaningful is that after "Set
AutoCommit On", when the first command is committed, it should commit
previous non-pending committed commands as well.
This is place when safety and and user friendly interface going against - the most safe behave is raising rollback there. But it can be in contrast with user's expectation.
>>
>> Not sure what benefit we will get by raising warning. I think it is
>> better to choose one behaviour (automatic commit or leave the
>> transaction open as is currently being done in psql) and make it
>> consistent across all clients.
>
>
> I am not sure about value of ecpg for this case. It is used by 0.0001%
> users. Probably nobody in Czech Republic knows this client.
>
Sure, but that doesn't give us the license for being inconsistent in
behaviour across different clients.
This is question. ecpg was designed years ago - and some details can be designed wrong.
Next question is design for interactive and non interactive usage.
> Warnings enforce the user do some decision
>
They could be annoying as well, especially if that happens in scripts.
in script - probably rollback is correct - script can be executed more time and user can fix it.
I am not sure if we can solve this issue as isolated problem. The first question should be - who, why and when does switching from autocommit off to on? How often this operation is? And we should be safe or we should not?
Regards
Pavel
В списке pgsql-hackers по дате отправления: