In cases where there was a boolean parsing failure, and ON_ERROR_STOP is
on, the error message no longer speak of a future which the session does
not have. I could left the ParseVariableBool() message as the only one, but
wasn't sure that that was enough of an error message on its own.
Added the test case to the existing tap tests. Incidentally, the tap tests
aren't presently fooled into thinking they're interactive.
Revised cumulative patch attached for those playing along at home.
It seems that ON_ERROR_STOP is mostly ignored by design when in
interactive mode, probably because it is nicer not to disconnect the user
who is actually typing things on a terminal.
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.
So, you must check for interactive as well when shortening the message,
and adapting it accordingly, otherwise on gets the wrong message in
bash> ./psql -v ON_ERROR_STOP=1
psql (10devel, server 9.6.1)
Type "help" for help.
calvin=# \if error
unrecognized value "error" for "\if <expr>": boolean expected
new \if is invalid.
calvin=# -- not stopped, but the stack has been cleaned up, I think
Basically it seems that there are 4 cases and 2 behaviors:
- on_error_stop && scripting:
actually exit on error
- on_error_stop && interactive, !on_error_stop whether scripting or not:
keep going, possibly with nesting checks?
The problem is that currently interactive behavior cannot be tested
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: