Re: Variable substitution in psql backtick expansion

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Corey Huinker <corey.huinker@gmail.com>
Cc: pgsql-hackers@postgresql.org
Date: 2017-03-31T16:58:55Z
Lists: pgsql-hackers

Attachments

Corey Huinker <corey.huinker@gmail.com> writes:
> On Thu, Mar 30, 2017 at 1:33 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> single-quoted according to Unix shell conventions.  (So the
>> processing would be a bit different from what it is for the
>> same notation in SQL contexts.)

> +1

Here's a proposed patch for this.  I used the existing appendShellString()
logic, which already knows how to quote stuff safely on both Unix and
Windows.  A small problem is that appendShellString() rejects LF and CR
characters.  As written, it just printed an error and did exit(1), which
is more or less OK for existing callers but seemed like a pretty bad idea
for psql.  I refactored it to get the behavior proposed in the patch,
which is that we print an error and decline to substitute the variable's
value, leading to executing the backtick command with the :'variable'
text still in place.  This is more or less the same thing that happens
for encoding-check failures in the other variable-substitution cases,
so it didn't seem too unreasonable.

Perhaps it would be preferable to prevent execution of the backtick
command and/or fail the calling metacommand, but that seems to require
some very invasive refactoring (or else magic global variables), which
I didn't have the appetite for.

			regards, tom lane

Commits

  1. Add psql variables showing server version and psql version.

  2. Reformat psql's --help=variables output.

  3. Remove reinvention of stringify macro.

  4. Allow psql variable substitution to occur in backtick command strings.