On Thu, Aug 11, 2016 at 8:34 AM, David G. Johnston
<david.g.johnston@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
