Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands:\quit_if, \quit_unless) - Mailing list pgsql-hackers

From Corey Huinker
Subject Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands:\quit_if, \quit_unless)
Date
Msg-id CADkLM=eTwrU-fA4K--9jDsfRe0OYV_qKGxXvoor3AEJVUnBWEQ@mail.gmail.com
Whole thread Raw
In response to Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)  ("Daniel Verite" <daniel@manitou-mail.org>)
Responses Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands:\quit_if, \quit_unless)  (Corey Huinker <corey.huinker@gmail.com>)
List pgsql-hackers
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.

I'd like to keep in sync with ParseVariableBoolean(), but 

Also, Fabien has made a good case for invalid parsed values being an ON_ERROR_STOP-able error, and not defaulted to either true or false.

This might be asking a lot, but could we make a "strict" mode for ParseVariableBool() that returns a success boolean, and have the existing ParseVariableBool() signature call that new function, and issue the "assuming " warning if the strict function failed?


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] lseek/read/write overhead becomes visible at scale ..
Next
From: Tobias Oberstein
Date:
Subject: Re: [HACKERS] lseek/read/write overhead becomes visible at scale ..