Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands:\quit_if, \quit_unless) - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands:\quit_if, \quit_unless)
Date
Msg-id alpine.DEB.2.20.1702070817490.26605@lancre
Whole thread Raw
In response to Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands:\quit_if, \quit_unless)  (Corey Huinker <corey.huinker@gmail.com>)
Responses Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands:\quit_if, \quit_unless)
List pgsql-hackers
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.



pgsql-hackers by date:

Previous
From: Petr Jelinek
Date:
Subject: Re: [HACKERS] IF [NOT] EXISTS for replication slots
Next
From: "Okano, Naoki"
Date:
Subject: Re: [HACKERS] Adding the optional clause 'AS' in CREATE TRIGGER