Re: Variable substitution in psql backtick expansion

From: "Daniel Verite" <daniel(at)manitou-mail(dot)org>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Fabien COELHO" <coelho(at)cri(dot)ensmp(dot)fr>,"PostgreSQL Developers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Variable substitution in psql backtick expansion
Date: 2017-04-03 16:33:06
Message-ID: fa259603-08ee-4394-ac3a-c7f4183fa8e2@manitou-mail.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:

> I really dislike this syntax proposal. It would get us into having
> to count nested brackets, and distinguish quoted from unquoted brackets,
> and so on ... and for what? It's not really better than
>
> \if sql select 1 from pg_catalog.pg_extension where extname='pgcrypto'
>
> (ie, "\if sql ...text to send to server...").

That's fine by me. The advantage of enclosing the query is to leave
open the possibility of accepting additional contents after the query,
like options (as \copy does), or other expression terms to combine
with the query's result. But we can live without that.

> If you're worried about shaving keystrokes, make the "select" be implicit.
> That would be particularly convenient for the common case where you're
> just trying to evaluate a boolean expression with no table reference.

These expressions look more natural without the SELECT keyword,
besides the size, but OTOH "\if sql 1 from table where expr"
looks awkward. Given an implicit select, I would prefer
"\if exists (select 1 from table where expr)" but now it's not shorter.

An advantage of prepending the SELECT automatically, is that it
would prevent people from abusing this syntax by putting
update/insert/delete or even DDL in there, imagining that this would
be a success/failure test for these operations.
Having these fail to execute in the first place, when called by \if,
seems like a sane failure mode that we would gain incidentally.

Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2017-04-03 16:33:07 Re: GSoC 2017 Proposal for "Explicitly support predicate locks in index access methods besides btree"
Previous Message Jeff Janes 2017-04-03 16:31:13 Can't compile with profiling after BRIN autosummarization