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
- variable-substitution-in-backticks-1.patch (text/x-diff) patch
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
-
Add psql variables showing server version and psql version.
- a6c678f018d3 10.0 landed
- 9ae9d8c1549c 11.0 landed
-
Reformat psql's --help=variables output.
- 3955c8c4eda2 11.0 landed
-
Remove reinvention of stringify macro.
- cd6baed78150 10.0 landed
-
Allow psql variable substitution to occur in backtick command strings.
- f833c847b8fa 10.0 landed