>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
