From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Daniel Verite" <daniel@manitou-mail.org>
cc: "Corey Huinker" <corey.huinker@gmail.com>,
        "Fabien COELHO" <coelho@cri.ensmp.fr>,
        "PostgreSQL" <pgsql-hackers@postgresql.org>
Subject: Re: \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if,
 \quit_unless)
In-reply-to: <0f307858-dfa2-4c5b-8ca5-febb398b3ccb@manitou-mail.org>
References: <0f307858-dfa2-4c5b-8ca5-febb398b3ccb@manitou-mail.org>
Comments: In-reply-to "Daniel Verite" <daniel@manitou-mail.org>
	message dated "Tue, 24 Jan 2017 19:08:08 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <10527.1485286713.1@sss.pgh.pa.us>
Date: Tue, 24 Jan 2017 14:38:33 -0500
Message-ID: <10528.1485286713@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

"Daniel Verite" <daniel@manitou-mail.org> writes:
> 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.

AFAIK we do have consensus on changing its behavior to disallow
assignment of invalid values.  It's just a matter of getting the
patch to be stylistically nice.

			regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers