From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Rahila Syed <rahilasyed90(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Surprising behaviour of \set AUTOCOMMIT ON |
Date: | 2016-08-06 06:12:55 |
Message-ID: | CAFj8pRAwXSYYL7rTOeXHufP6_YssGFJYVX=AgVp7YYrinSSB1Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2016-08-06 7:29 GMT+02:00 Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>:
> On Thu, Aug 4, 2016 at 7:46 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
>
> > 2016-08-04 15:37 GMT+02:00 Amit Kapila <amit(dot)kapila16(at)gmail(dot)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
>
>
> --
> With Regards,
> Amit Kapila.
> EnterpriseDB: http://www.enterprisedb.com
>
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2016-08-06 06:18:56 | Re: Possible duplicate release of buffer lock. |
Previous Message | Amit Kapila | 2016-08-06 05:29:08 | Re: Surprising behaviour of \set AUTOCOMMIT ON |