Re: Surprising behaviour of \set AUTOCOMMIT ON

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

Throwing psql error comes out to be most accepted outcome on this thread. I
agree it is safer than guessing user intention.

Although according to the default behaviour of psql, error will abort the
current transaction and roll back all the previous commands. This can be
user unfriendly making user rerun all the commands just because of
autocommit switch. So probably behaviour of 'ON_ERROR_ROLLBACK on' needs to
be implemented along with the error display. This will rollback just the
autocommit switch command.

Also, psql error instead of a simple commit will lead to script
terminations. Hence issuing a COMMIT seems more viable here. However,
script termination can be avoided by default behaviour of ON_ERROR_STOP
which will execute subsequent commands successfully.(However subsequent
commands won't be executed in autocommit mode which I think should be OK as
it will be notified via ERROR).

So summarizing my view of the discussion on this thread, issuing a psql
error seems to be the best option. I will post a patch regarding this if
there is no objection.

Thank you,

Rahila Syed