Re: Variable substitution in psql backtick expansion

David G. Johnston <david.g.johnston@gmail.com>

From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Daniel Verite <daniel@manitou-mail.org>
Cc: Fabien COELHO <coelho@cri.ensmp.fr>, Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL Developers <pgsql-hackers@postgresql.org>
Date: 2017-04-03T22:43:59Z
Lists: pgsql-hackers
On Mon, Apr 3, 2017 at 5:12 AM, Daniel Verite <daniel@manitou-mail.org>
wrote:

> Queries can be as complex as necessary, they just have to fit in one line.


​Line continuation in general is missed though I thought something already
when in for 10.0 that improves upon this...​


> In no way at all,in the sense that, either you choose to use an SQL
> evaluator, or a client-side evaluator (if it exists), or a backtick
> expression.
> They are mutually exclusive for a single \if invocation.
>
> Client-side evaluation would have to be called with a syntax
> that is unambiguously different.


​Is that the universe: server, client, shell?

Shell already has backticks required
​Server, being the most common, ideally wouldn't need demarcation
Client thus would want its own symbol pairing to distinguish it from server.

Server doesn't need a leading marker but do we want to limit it to single
statements only and allow an optional trailing semi-colon (or backslash
command) which, if present, would end the "server" portion of the string
and allow for treatment of additional terms on the same line to be parsed
in a different context?

I'm conceptually for the implied "SELECT" idea.  It overlaps with plpgsql
syntax.

David J.

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.