Re: Variable substitution in psql backtick expansion

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Variable substitution in psql backtick expansion
Date: 2017-03-31 16:58:55
Message-ID: 7430.1490979535@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Corey Huinker <corey(dot)huinker(at)gmail(dot)com> writes:
> On Thu, Mar 30, 2017 at 1:33 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

Attachment Content-Type Size
variable-substitution-in-backticks-1.patch text/x-diff 18.7 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2017-03-31 17:20:51 Re: delta relations in AFTER triggers
Previous Message Jeff Janes 2017-03-31 16:32:50 Re: postgres_fdw bug in 9.6