From: Tom Lane <tgl@sss.pgh.pa.us>
To: Corey Huinker <corey.huinker@gmail.com>
cc: Fabien COELHO <coelho@cri.ensmp.fr>,
        Daniel Verite <daniel@manitou-mail.org>,
        "David G. Johnston" <david.g.johnston@gmail.com>,
        Greg Stark <stark@mit.edu>, Erik Rijkers <er@xs4all.nl>,
        Robert Haas <robertmhaas@gmail.com>,
        Jim Nasby <Jim.Nasby@bluetreble.com>,
        PostgreSQL <pgsql-hackers@postgresql.org>,
        pgsql-hackers-owner@postgresql.org
Subject: Re: \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if,
 \quit_unless)
In-reply-to: 
 <CADkLM=f3n9FR+fV+Lt+aVOinTZwC1BiBbYTOKYLt+Gv4OCL5jw@mail.gmail.com>
References: <df2c433c-b9ff-4d41-ad08-b0d420b403b8@manitou-mail.org>
 <15875.1489440118@sss.pgh.pa.us>
 <CADkLM=fzjNr2it+a75CJgs7nPPSb-S=q=taa7=7mtxa5pKJSbQ@mail.gmail.com>
 <24741.1489698878@sss.pgh.pa.us>
 <CADkLM=fHrBW4Z+ixPD35Ad+4oKG1KX0UK7xDY+0G9gdNnDQS8A@mail.gmail.com>
 <alpine.DEB.2.20.1703170710320.4278@lancre> <30537.1489761433@sss.pgh.pa.us>
 <alpine.DEB.2.20.1703171553550.21944@lancre> <11743.1489765330@sss.pgh.pa.us>
 <CADkLM=f3n9FR+fV+Lt+aVOinTZwC1BiBbYTOKYLt+Gv4OCL5jw@mail.gmail.com>
Comments: In-reply-to Corey Huinker <corey.huinker@gmail.com>
	message dated "Fri, 17 Mar 2017 12:03:01 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <13602.1489768437.1@sss.pgh.pa.us>
Date: Fri, 17 Mar 2017 12:33:57 -0400
Message-ID: <13603.1489768437@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Corey Huinker <corey.huinker@gmail.com> writes:
> I think Fabien was arguing that inside a false block there would be no
> syntax rules beyond "is the first non-space character on this line a '\'
> and if so is it followed with a if/elif/else/endif?". If the answer is no,
> skip the line. To me that seems somewhat similar to Tom's suggestion that a
> false branch just keeps consuming text until it encounters a \conditional
> or EOF.

Hmm.  If we can keep the syntax requirements down to "\if and friends
must be the first backslash command on the line", and not change the
apparent behavior for any other command type, it probably would be okay
from the user's standpoint.  I'm not really convinced that this approach
will accomplish that, though, and especially not that it will do so
without injecting some ugliness into the core lexer.

In the end, I suspect that teaching all the backslash commands to do
nothing after absorbing their arguments is likely to be the least messy
way to tackle this, even if it makes for a rather bulky patch.

			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