Re: Variable substitution in psql backtick expansion

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Daniel Verite <daniel(at)manitou-mail(dot)org>
Cc: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Variable substitution in psql backtick expansion
Date: 2017-04-03 22:43:59
Message-ID: CAKFQuwYp_tDbmrLShp_g-LtxpY7yv5GJ56ukjSgTCSq-W7U35w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Apr 3, 2017 at 5:12 AM, Daniel Verite <daniel(at)manitou-mail(dot)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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Van Fleet 2017-04-03 23:19:20 Re: Should we cacheline align PGXACT?
Previous Message Stephen Frost 2017-04-03 22:38:59 Re: Rewriting the test of pg_upgrade as a TAP test