On Tue, Jan 24, 2017 at 1:15 AM, Fabien COELHO <coe...@cri.ensmp.fr> wrote:
> > 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). > The docs (doc/src/sgml/datatype.sgml) list TRUE 't' 'true' 'y' 'yes' 'on' '1' vs FALSE 'f' 'false' 'n' 'no' 'off' '0' However, src/test/regress/expected/boolean.out shows that there's some flexiblity there with spaces, even before you inspect parse_bool_with_len() in src/backend/utils/adt/bool.c. If we could bring src/backend/utils/adt/bool.c across the server/client wall, I would just use parse_bool_with_len as-is. As it is, given that whatever I do is temporary until real expressions come into place, that wouldn't be a terrible amount of code copying, and we'd still have a proto-expression that probably isn't going to conflict with whatever expression syntax we do chose. Having said that, if anyone can see ANY reason that some subset of the existing bool-friendly strings would cause a problem with the expression syntax we do hope to use, speak now and we can restrict the accepted values. > I would suggest to assume false on everything else, and/or maybe to ignore > the whole if/endif section in such cases. +1, it also halves the number of values we have to support later. > ISTM that with TAP test you can check for error returns, so maybe this can > be done. I'll have to educate myself on TAP tests.
