Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands:\quit_if, \quit_unless)

I did some more tests. I found a subtlety that I missed before: when running under ON_ERROR_STOP, messages are not fully consistent:

 sh> cat test.sql
 \set ON_ERROR_STOP on
 \if error
   \echo NO
 \endif
 \echo NO

 sh> ./psql < test.sql
 SET
 # ok
 unrecognized value "error" for "\if <expr>": boolean expected
 # ok

That's straight from ParseVariableBool, and we can keep that or suppress it. Whatever we do, we should do it with the notion that more complex expressions will eventually be allowed, but they'll still have to resolve to something that's a text boolean. 

 

 new \if is invalid, ignoring commands until next \endif
 # hmmm... but it does not, it is really stopping immediately...

 found EOF before closing \endif(s)
 # no, it has just stopped before EOF because of the error...

Yeah, chattiness caught up to us here. Both of these messages can be suppressed, I think.

 

Also I'm not quite sure why psql decided that it is in interactive mode above, its stdin is a file, but why not.

The issue is made more explicit with -f:

 sh> ./psql -f test.sql
 SET
 psql:test.sql:2: unrecognized value "error" for "\if <expr>": boolean expected
 psql:test.sql:2: new \if is invalid, ignoring commands until next \endif
 psql:test.sql:2: found EOF before closing \endif(s)

It stopped on line 2, which is expected, but it was not on EOF.

I think that the message when stopping should be ", stopping as required by ON_ERROR_STOP" or something like that instead of ", ignoring...", and the EOF message should not be printed at all in this case.

I agree, and will look into making that happen. Thanks for the test case.