pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Daniel Verite <daniel@manitou-mail.org>
Cc: David G. Johnston <david.g.johnston@gmail.com>
Cc: Corey Huinker <corey.huinker@gmail.com>
Cc: Fabien COELHO <coelho@cri.ensmp.fr>
Cc: Greg Stark <stark@mit.edu>
Cc: Erik Rijkers <er@xs4all.nl>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Jim Nasby <Jim.Nasby@bluetreble.com>
Cc: PostgreSQL <pgsql-hackers@postgresql.org>
Cc: pgsql-hackers-owner@postgresql.org
Subject: Re: \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)
Date: Mon, 13 Mar 2017 17:21:58 -0400
Message-ID: <15875.1489440118@sss.pgh.pa.us> (raw)
In-Reply-To: <df2c433c-b9ff-4d41-ad08-b0d420b403b8@manitou-mail.org>
References: <df2c433c-b9ff-4d41-ad08-b0d420b403b8@manitou-mail.org>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>

"Daniel Verite" <daniel@manitou-mail.org> writes:
> Tom Lane wrote:
>> when we see \if is that we do nothing but absorb text
>> until we see the matching \endif.  At that point we could bitch and throw
>> everything away if, say, there's \elif after \else, or anything else you
>> want to regard as a "compile time error".  Otherwise we start execution,
>> and from there on it probably has to behave as we've been discussing.
>> But this'd be pretty unfriendly from an interactive standpoint, and I'm
>> not really convinced that it makes for significantly better error
>> reporting.

> On the whole, isn't that a reasonable model to follow for psql?

One thing that occurs to me after more thought is that with such a model,
we could not have different lexing rules for live vs not-live branches,
since we would not have made those decisions before scanning the input.
This seems problematic.  Even if you discount the question of whether
variable expansion is allowed to change command-boundary decisions, we'd
still not want backtick execution to happen everywhere in the block, ISTM.

Maybe we could fix things so that backtick execution happens later, but
it would be a pretty significant and invasive change to backslash command
execution, I'm afraid.

			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



view thread (232+ messages)  latest in thread

Message-ID: <15875.1489440118@sss.pgh.pa.us>
Permalink:  ../15875.1489440118@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/15875.1489440118@sss.pgh.pa.us

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tgl@sss.pgh.pa.us, daniel@manitou-mail.org, david.g.johnston@gmail.com, corey.huinker@gmail.com, coelho@cri.ensmp.fr, stark@mit.edu, er@xs4all.nl, robertmhaas@gmail.com, Jim.Nasby@bluetreble.com, pgsql-hackers-owner@postgresql.org
  Subject: Re: \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)
  In-Reply-To: <15875.1489440118@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox