From: Tom Lane <tgl@sss.pgh.pa.us>
To: Daniel Verite <daniel@manitou-mail.org>
Cc: Corey Huinker <corey.huinker@gmail.com>
Cc: David G. Johnston <david.g.johnston@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: Fri, 17 Mar 2017 09:33:24 -0400
Message-ID: <28273.1489757604@sss.pgh.pa.us> (raw)
In-Reply-To: <9cdc09f7-8e5c-43c9-9c00-2e3bbb69b9ef@manitou-mail.org>
References: <9cdc09f7-8e5c-43c9-9c00-2e3bbb69b9ef@manitou-mail.org>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
"Daniel Verite" <daniel@manitou-mail.org> writes:
> Tom Lane wrote:
>> OT_WHOLE_LINE is not what you want because that results in verbatim
>> copying, without variable expansion or anything
> But if we want to implement "\if defined :foo" in the future
> isn't it just what we need?
I don't think that should mean what you think. I believe an appropriate
spelling of what you mean is "\if defined foo". What you wrote should
result in foo being expanded and then a defined-ness test being performed
on whatever variable name results.
> Also we could leave open the option to accept an SQL expression
> here. I expect people will need SQL as the evaluator in a lot of cases.
Right, and they'll also want to insert variable references into that
SQL. In the short term though, `expr ...` is going to be the solution,
and that means we'd better not throw away the behavior of expanding
back-ticks.
> There's a precedent with \copy accepting a query inside parentheses,
> using OT_WHOLE_LINE.
IMV, \copy is just about completely broken in this regard, precisely
because it fails to expand variable references. I don't want to
emulate that brain-damage for \if. (I believe, btw, that part
of the reason for \copy behaving this way is that we wanted to
preserve an ancient behavior whereby Windows users were not forced
to double backslashes in \windows\style\path\names. Fortunately,
that bit of silliness need not be considered for \if.)
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
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, corey.huinker@gmail.com, david.g.johnston@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: <28273.1489757604@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