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.


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.


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.


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to