Re: Variable substitution in psql backtick expansion - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Variable substitution in psql backtick expansion
Date
Msg-id 2901.1490973163@sss.pgh.pa.us
Whole thread Raw
In response to Variable substitution in psql backtick expansion  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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.)

> Any reason we wouldn't do :"VARIABLE" as well?

Well, what would that mean exactly?  The charter of :'FOO', I think,
is to get the string value through shell parsing unscathed.  I'm a
lot less clear on what :"FOO" ought to do.  If it has any use then
I'd imagine that that includes allowing $shell_variable references in
the string to become expanded.  But then you have a situation where some
shell special characters in the string are supposed to take effect but
others presumably still aren't.  Figuring out the exact semantics would
take some specific use-cases, and more time than I really have available
right now.

In short, that's something I thought was best left as a later
refinement, rather than doing a rush job we might regret.

> People might expect it given
> its use elsewhere, and it would make possible things like

> SELECT '$HOME/lamentable application name dir/bin/myprog' as myprog \gset
> `:"myprog" arg1 arg2`

You could get about 80% of the way there with `":myprog" arg1 arg2`,
since backtick processing doesn't have any rule that would prevent
:myprog from being expanded inside shell double quotes.
        regards, tom lane



pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: [PATCH] Transaction traceability - txid_status(bigint)
Next
From: Tom Lane
Date:
Subject: Re: Variable substitution in psql backtick expansion