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 |
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 |