> > 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.
