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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
