Re: Improvements in psql hooks for variables
Daniel Verite <daniel@manitou-mail.org>
From: "Daniel Verite" <daniel@manitou-mail.org>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Stephen Frost" <sfrost@snowman.net>,"Rahila Syed"
<rahilasyed90@gmail.com>,"Ashutosh Bapat"
<ashutosh.bapat@enterprisedb.com>,"pgsql-hackers"
<pgsql-hackers@postgresql.org>
Date: 2016-11-21T13:29:57Z
Lists: pgsql-hackers
Tom Lane wrote: > 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. Exactly. The scope of the patch is limited to the effect of \set assignments to built-in variables. > 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. +1 Best regards, -- Daniel Vérité PostgreSQL-powered mailer: http://www.manitou-mail.org Twitter: @DanielVerite
Commits
-
Clean up psql's behavior for a few more control variables.
- fd6cd698031d 10.0 landed
-
Make psql's \set display variables in alphabetical order.
- c3e3844a92fe 10.0 landed
-
Improve psql's behavior for \set and \unset of its control variables.
- 86322dc7e013 10.0 landed
-
Make psql reject attempts to set special variables to invalid values.
- 511ae628f31b 10.0 landed