On Fri, Aug 12, 2016 at 3:03 PM, Robert Haas <robertmh...@gmail.com> wrote:
> 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. > > Changing AUTOCOMMIT to ON while in a transaction is a psql error - period. If ON_ERROR_STOP is on we stop. This meets the current semantics for ON_ERROR_STOP. With ON_ERROR_STOP off psql is going to continue on with the next command. I'd suggest changing things so that psql can, depending upon the error, invoke additional commands to bring the system into a known good state before the next user command is executed. In the case of "\set AUTOCOMMIT on" this additional command would be COMMIT. We can still report the error before continuing on - so there is no affecting the "generating [of] an error in the first place.". Allowing command-specific responses to errors when faced with script continuation would be a change. I do not think it would be a bad one. Am I stretching a bit here? Sure. Is it worth stretching to avoid adding more knobs to the system? Maybe. I'll admit I haven't tried to find fault with the idea (or discover better alternatives) nor how it would look in implementation. As a user, though, it would make sense if the system behaved in this way. That only AUTOCOMMIT needs this capability at the moment doesn't bother me. I'm also fine with making it an error and moving on - but if you want to accommodate both possibilities this seems like a cleaner solution than yet another environment variable that a user would need to consider. David J.
