Hello Corey,
> 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.
Yes.
> Revised cumulative patch attached for those playing along at home.
Nearly there...
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.
""" ON_ERROR_STOP
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
interactive mode:
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
automatically.
--
Fabien.