> 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?
