From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stephen Frost <sfrost@snowman.net>
cc: Daniel Verite <daniel@manitou-mail.org>,
        Rahila Syed <rahilasyed90@gmail.com>,
        Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>,
        pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Improvements in psql hooks for variables
In-reply-to: <20161119233603.GC13284@tamriel.snowman.net>
References: 
 <CAH2L28tsJWuYtcbqgWYmdeuXshiPFta6S1OxOx5_O62Xss8r6g@mail.gmail.com>
 <b0c61324-8ad3-413e-bb88-5c71d6412bba@mm>
 <20161119233603.GC13284@tamriel.snowman.net>
Comments: In-reply-to Stephen Frost <sfrost@snowman.net>
	message dated "Sat, 19 Nov 2016 18:36:03 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7463.1479599073.1@sss.pgh.pa.us>
Date: Sat, 19 Nov 2016 18:44:33 -0500
Message-ID: <7464.1479599073@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Stephen Frost <sfrost@snowman.net> writes:
> In reviewing this patch, I also noticed that it's set up to assume a
> 'true' result when a variable can't be parsed by ParseVariableBool.

I suppose that's meant to be backwards-compatible with the current
behavior:

regression=# \timing foo
unrecognized value "foo" for "\timing"; assuming "on"
Timing is on.

but I agree that if we're changing things in this area, that would
be high on my list of things to change.  I think what we want going
forward is to disallow setting "special" variables to invalid values,
and that should hold both for regular variables that have special
behaviors, and for the special-syntax cases like \timing.

			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