Re: Surprising behaviour of \set AUTOCOMMIT ON - Mailing list pgsql-hackers
| From | David G. Johnston |
|---|---|
| Subject | Re: Surprising behaviour of \set AUTOCOMMIT ON |
| Date | |
| Msg-id | CAKFQuwa8BaDVqJP5XXr=ConodXvM=17gNeCeuC36Mafu=G=yTw@mail.gmail.com Whole thread Raw |
| In response to | Re: Surprising behaviour of \set AUTOCOMMIT ON (Robert Haas <robertmhaas@gmail.com>) |
| Responses |
Re: Surprising behaviour of \set AUTOCOMMIT ON
(Amit Kapila <amit.kapila16@gmail.com>)
|
| List | pgsql-hackers |
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.
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.
pgsql-hackers by date: