Corey Huinker 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
The patch at https://commitfest.postgresql.org/12/799/ in the ongoing CF already changes ParseVariableBool() to not assume that unrecognizable values should be set to "on". There's also the fact that ParseVariableBool() in HEAD assumes that an empty value is valid and true, which I think leads to this inconsistency in the current patch: \set empty \if :empty select 1 as result \gset \else select 2 as result \gset \endif \echo 'result is' :result produces: result is 1 (so an empty string evaluates to true) Yet this sequence: \if select 1 as result \gset \else select 2 as result \gset \endif \echo 'result is' :result produces: result is 2 (so an empty \if evaluates to false) The equivalence between empty value and true in ParseVariableBool() is also suppressed in the above-mentioned patch. ISTM that it's important that eventually ParseVariableBool() and \if agree on what evaluates to true and false (and the more straightforward way to achieve that is by \if calling directly ParseVariableBool), but that it's not productive that we discuss /if issues relatively to the behavior of ParseVariableBool() in HEAD at the moment, as it's likely to change. Best regards, -- Daniel Vérité PostgreSQL-powered mailer: http://www.manitou-mail.org Twitter: @DanielVerite -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
