>> 1: unrecognized value "whatever" for "\if"; assuming "on"
>>
>> I do not think that the script should continue with such an assumption.
>
> I agree, and this means we can't use ParseVariableBool() as-is. I
> already broke out argument reading to it's own function, knowing that
> it'd be the stub for expressions. So I guess we start that now. What
> subset of true-ish values do you think we should support? If we think
> that real expressions are possible soon, we could only allow 'true' and
> 'false' for now, but if we expect that expressions might not make it
> into v10, then perhaps we should support the same text values that
> coerce to booleans on the server side.
Hmmm. I would text value that coerce to true? I would also accept non-zero
integers (eg SELECT 1::BOOL; -- t).
I would suggest to assume false on everything else, and/or maybe to ignore
the whole if/endif section in such cases.
> All valid issues. Will add those to the regression as well (with
> ON_ERROR_STOP disabled, obviously).
ISTM that with TAP test you can check for error returns, so maybe this can
be done.
--
Fabien.
