Re: Improvements in psql hooks for variables

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Daniel Verite <daniel@manitou-mail.org>
Cc: Rahila Syed <rahilasyed90@gmail.com>, Stephen Frost <sfrost@snowman.net>, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Andrew Dunstan <andrew@dunslane.net>
Date: 2017-01-31T00:13:40Z
Lists: pgsql-hackers
So I pushed this, and the buildfarm members that are testing RedisFDW
immediately fell over:

*** /home/andrew/bf/root/HEAD/redis_fdw.build/test/expected/redis_fdw.out	2017-01-30 18:20:27.440677318 -0500
--- /home/andrew/bf/root/HEAD/redis_fdw.build/test/results/redis_fdw.out	2017-01-30 18:32:33.404677320 -0500
***************
*** 26,31 ****
--- 26,32 ----
         options (database '15', tabletype 'zset');
  -- make sure they are all empty - if any are not stop the script right now
  \set ON_ERROR_STOP
+ unrecognized value "" for "ON_ERROR_STOP": boolean expected
  do $$
    declare
      rows bigint;

======================================================================

Evidently, this test script is relying on the preceding behavior that
setting a bool variable to an empty string was equivalent to setting
it to "true".  If it's just that script I would be okay with saying
"well, it's a bug in that script" ... but I'm a bit worried that this
may be the tip of the iceberg, ie maybe a lot of people have done
things like this.  Should we reconsider the decision to reject empty
strings in ParseVariableBool?

			regards, tom lane


Commits

  1. Clean up psql's behavior for a few more control variables.

  2. Make psql's \set display variables in alphabetical order.

  3. Improve psql's behavior for \set and \unset of its control variables.

  4. Make psql reject attempts to set special variables to invalid values.