Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cYM6T-0002fc-7A for pgsql-hackers@arkaria.postgresql.org; Tue, 31 Jan 2017 00:15:21 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1cYM6S-000723-NN for pgsql-hackers@arkaria.postgresql.org; Tue, 31 Jan 2017 00:15:20 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cYM53-00049L-7u for pgsql-hackers@postgresql.org; Tue, 31 Jan 2017 00:13:53 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cYM50-0005Bm-6m for pgsql-hackers@postgresql.org; Tue, 31 Jan 2017 00:13:52 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id v0V0Dewn009575; Mon, 30 Jan 2017 19:13:40 -0500 From: Tom Lane To: Daniel Verite cc: Rahila Syed , Stephen Frost , Ashutosh Bapat , pgsql-hackers , Andrew Dunstan Subject: Re: Improvements in psql hooks for variables In-reply-to: <3196.1485808893@sss.pgh.pa.us> References: <11456.1485288184@sss.pgh.pa.us> <17593.1485798464@sss.pgh.pa.us> <3196.1485808893@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Mon, 30 Jan 2017 15:41:33 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9571.1485821620.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Jan 2017 19:13:40 -0500 Message-ID: <9572.1485821620@sss.pgh.pa.us> X-Pg-Spam-Score: -5.1 (-----) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org 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 2= 017-01-30 18:20:27.440677318 -0500 --- /home/andrew/bf/root/HEAD/redis_fdw.build/test/results/redis_fdw.out 20= 17-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; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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 --=20 Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers