Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cgg88-0006hc-AT for pgsql-hackers@arkaria.postgresql.org; Wed, 22 Feb 2017 23:15:28 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1cgg87-0006DR-P2 for pgsql-hackers@arkaria.postgresql.org; Wed, 22 Feb 2017 23:15:27 +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 1cgg86-0006CT-AM; Wed, 22 Feb 2017 23:15:26 +0000 Received: from mail-yw0-x22a.google.com ([2607:f8b0:4002:c05::22a]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1cgg83-00012v-Ry; Wed, 22 Feb 2017 23:15:25 +0000 Received: by mail-yw0-x22a.google.com with SMTP id l19so9124142ywc.2; Wed, 22 Feb 2017 15:15:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pTUkxrkjYf6ukuQFPv1E7hIMvolPlLKQ48wYw2LUxWk=; b=s3qiCAQCJQeXA8Q0wkI7natR9eiOIglQ43CI9S44OpwnJQlEOlmkwzQct8XmKSXtVC YKvSgrRRaIf6jAWAMLuN5j793I3vFZGdCdjP38A5p/78W5X17duIMUBLbuUG5vz0cWxj WC3RDNEj+rKVa8xQUSoPI0gyU2v2TwfY702vu8Zf7/MJD3EmmY60sLK1x6jpGEbuBS7E 0oLy1s2hiniT8DJS465BkCzWg40evaSVslZl+XwJaJKYEOcW8wL9ylSGQVHFX0f/S2t8 +Oc6O+qmBgzord9guWf8ibw9vAbm06CWb3qRR4nB3+p4hosQWD70PLRxUHRBZPiauSYt KadQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pTUkxrkjYf6ukuQFPv1E7hIMvolPlLKQ48wYw2LUxWk=; b=o24iTkHSgRjlM7B18ovDP8oNUW6MPWUQQfSj0a5y0pUYqi2os0EC3zepFYyrM+ye5T 1l8vikvNwhGmhaZvDXN2FHENyHpW6r5nOEPoJHjga56MeI0lkZktoi84B2yrM1w2osDp UZJgBsi/mqNPra3SsozNEpY7CFu/KgxXgWO1x3u0eG6y+109k3HEwH3gkvoLje+/SHXg UzaBhcwiwehYfwPw1yPdJk9n61E7XHwIAV2OHM9AKJsFkEkU/b7PmYr6ZuLOYZW8+Odb WcL0JGOLhiiK8VAdZCKJzno7s+R35gShsK7fHw/BU+UuKj+fa9DVTcnBi4d+E95ZL7kD zMpw== X-Gm-Message-State: AMke39kGn2lupiqydX8NyzWvZ1Djeb9cqMLgqDsF1NtybiKP7w4GCBdDhhH5884dLj1ijELy7lxagwp14bBCLQ== X-Received: by 10.129.157.202 with SMTP id u193mr15214378ywg.12.1487805321724; Wed, 22 Feb 2017 15:15:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.165.132 with HTTP; Wed, 22 Feb 2017 15:15:01 -0800 (PST) In-Reply-To: <21888.1487804399@sss.pgh.pa.us> References: <24063.1486671184@sss.pgh.pa.us> <5095.1486674948@sss.pgh.pa.us> <4fb8635d88c7dc907d069e15fdd1ab94@xs4all.nl> <28640.1487108678@sss.pgh.pa.us> <16856.1487797250@sss.pgh.pa.us> <18672.1487799954@sss.pgh.pa.us> <21888.1487804399@sss.pgh.pa.us> From: Corey Huinker Date: Wed, 22 Feb 2017 18:15:01 -0500 Message-ID: Subject: Re: \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless) To: Tom Lane Cc: Fabien COELHO , Greg Stark , Erik Rijkers , Robert Haas , Daniel Verite , Jim Nasby , PostgreSQL , pgsql-hackers-owner@postgresql.org Content-Type: multipart/alternative; boundary=94eb2c0badb2b24bf8054926ab40 X-Pg-Spam-Score: -2.7 (--) 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 --94eb2c0badb2b24bf8054926ab40 Content-Type: text/plain; charset=UTF-8 On Wed, Feb 22, 2017 at 5:59 PM, Tom Lane wrote: > Ah, I see why *that* wants to know about it ... I think. I suppose you're > arguing that variable expansion shouldn't be able to insert, say, an \else > in a non-active branch? Maybe, but if it can insert an \else in an active > branch, then why not non-active too? Seems a bit inconsistent. > The major reason was avoiding situations like what Daniel showed: where value of a variable that is meaningless/undefined in the current false-block context gets expanded anyway, and thus code inside a false block has effects outside of that block. Granted, his example was contrived. I'm open to removing that feature and seeing what breaks in the test cases. --94eb2c0badb2b24bf8054926ab40 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 22, 2017 at 5:59 PM, Tom Lane <tgl@sss.pgh.pa.us> wr= ote:
Ah, I see why *that* wants to know about it ... I think.= =C2=A0 I suppose you're
arguing that variable expansion shouldn't be able to insert, say, an \e= lse
in a non-active branch?=C2=A0 Maybe, but if it can insert an \else in an ac= tive
branch, then why not non-active too?=C2=A0 Seems a bit inconsistent.
<= /blockquote>

The major reason was avoiding situations like what Da= niel showed: where value of a variable that is meaningless/undefined in the= current false-block context gets expanded anyway, and thus code inside a f= alse block has effects outside of that block. Granted, his example was cont= rived. I'm open to removing that feature and seeing what breaks in the = test cases.
--94eb2c0badb2b24bf8054926ab40--