On Mon, Aug 8, 2016 at 11:17 AM, David G. Johnston <david.g.johns...@gmail.com> wrote: > On Mon, Aug 8, 2016 at 11:02 AM, Robert Haas <robertmh...@gmail.com> wrote: >> >> On Mon, Aug 8, 2016 at 10:10 AM, Rahila Syed <rahilasye...@gmail.com> >> wrote: >> > Thank you for inputs everyone. >> > >> > The opinions on this thread can be classified into following >> > 1. Commit >> > 2. Rollback >> > 3. Error >> > 4. Warning >> > >> > As per opinion upthread, issuing implicit commit immediately after >> > switching >> > autocommit to ON, can be unsafe if it was not desired. While I agree >> > that >> > its difficult to judge users intention here, but if we were to base it >> > on >> > some assumption, the closest would be implicit COMMIT in my >> > opinion.There is >> > higher likelihood of a user being happy with issuing a commit when >> > setting >> > autocommit ON than a transaction being rolled back. Also there are >> > quite >> > some interfaces which provide this. >> > >> > As mentioned upthread, issuing a warning on switching back to autocommit >> > will not be effective inside a script. It won't allow subsequent >> > commands to >> > be committed as set autocommit to ON is not committed. Scripts will have >> > to >> > be rerun with changes which will impact user friendliness. >> > >> > While I agree that issuing an ERROR and rolling back the transaction >> > ranks >> > higher in safe behaviour, it is not as common (according to instances >> > stated >> > upthread) as immediately committing any open transaction when switching >> > back >> > to autocommit. >> >> I think I like the option of having psql issue an error. On the >> server side, the transaction would still be open, but the user would >> receive a psql error message and the autocommit setting would not be >> changed. So the user could type COMMIT or ROLLBACK manually and then >> retry changing the value of the setting. >> >> Alternatively, I also think it would be sensible to issue an immediate >> COMMIT when the autocommit setting is changed from off to on. That >> was my first reaction. >> >> Aborting the server-side transaction - with or without notice - >> doesn't seem very reasonable. >> > > Best of both worlds? > > IF (ON_ERROR_STOP == 1) > THEN (treat this like any other error) > ELSE (send COMMIT; to server)
No, that's not a good idea. The purpose of ON_ERROR_STOP is something else entirely, and we shouldn't reuse it for an unrelated purpose. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
