On Thu, Aug 11, 2016 at 8:34 AM, David G. Johnston <david.g.johns...@gmail.com> wrote: > I don't have a fundamental issue with saying "when turning auto-commit on > you are also requesting that the open transaction, if there is one, is > committed immediately." I'm more inclined to think an error is the correct > solution - or to respond in a way conditional to the present usage > (interactive vs. script). I disagree with Robert's unsubstantiated belief > regarding ON_ERROR_STOP and think that it captures the relevant user-intent > for this behavior as well.
I'll substantiate my belief by referring to you for the documentation for ON_ERROR_STOP, which says: "By default, command processing continues after an error. When this variable is set to on, processing will instead stop immediately. In interactive mode, psql will return to the command prompt; otherwise, psql will exit, returning error code 3 to distinguish this case from fatal error conditions, which are reported using error code 1. In either case, any currently running scripts (the top-level script, if any, and any other scripts which it may have in invoked) will be terminated immediately. If the top-level command string contained multiple SQL commands, processing will stop with the current command." In every existing case, ON_ERROR_STOP affects whether we continue to process further commands after an error has already occurred. Your proposal would involve changing things so that the value ON_ERROR_STOP affects not only *how errors are handled* but *whether they happen in the first place* -- but only in this one really specific case, and no others. This isn't really an arguable point, even if you want to try to pretend otherwise. ON_ERROR_STOP should affect whether we stop on error, not whether generate an error in the first place. The clue is in the name. -- 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
