Re: Surprising behaviour of \set AUTOCOMMIT ON
| От | Pavel Stehule |
|---|---|
| Тема | Re: Surprising behaviour of \set AUTOCOMMIT ON |
| Дата | |
| Msg-id | CAFj8pRAtnAQmG2hmvy_xknmW4WUkSvgYtByqYvpdXB8mjGSfBw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Surprising behaviour of \set AUTOCOMMIT ON (Amit Kapila <amit.kapila16@gmail.com>) |
| Ответы |
Re: Surprising behaviour of \set AUTOCOMMIT ON
|
| Список | pgsql-hackers |
2016-08-04 15:37 GMT+02:00 Amit Kapila <amit.kapila16@gmail.com>:
On Wed, Aug 3, 2016 at 5:09 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>
>
> 2016-08-03 12:16 GMT+02:00 Rahila Syed <rahilasyed90@gmail.com>:
>>
>> Should changing the value from OFF to ON automatically either commit or
>> rollback transaction in progress?
>>
>>
>> FWIW, running set autocommit through ecpg commits the ongoing transaction
>> when autocommit is set to ON from OFF. Should such behaviour be implemented
>> for \set AUTOCOMMIT ON as well?
>
>
> 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 - ROLLBACK can be unfriendly surprising.
> What about raising warning if
> some transaction is open?
>
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.
Warnings enforce the user do some decision - I don't think so we can do this decision well.
Regards
Pavel
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: