Re: Variable substitution in psql backtick expansion

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, Daniel Verite <daniel(at)manitou-mail(dot)org>, 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-17 07:01:22
Message-ID: CAFj8pRBiHg49uFdQEkAKG0bO1o7TgZJcJc26_kzQT00ZdS2xyg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
>
> 4. because pgbench doesn't do early variable evaluation, implementation of
>> "defined" function is easy - we can introduce some new syntax for
>> implementation some bash patterns like "default value" or "own undefined
>> message"
>>
>
> Maybe. ISTM that a :* syntax should be thought for so that it always work
> where variable can be used, not only within client side expressions.
>

has sense

>
> Consider:
>
> \set port 5432
>
> Then you can write:
>
> SELECT :port ;
> -- 5432
>
> And it currently works as expected in SQL. Now I think that the same
> behavior is desirable for variable definition testing, i.e. with a :*
> syntax the substitution can be performed everywhere, eg with:
>
> \if ...
> \set port 5432
> \endif
>
> Then it would work both client side:
>
> \let port_is_defined :?port
>
> and also server side:
>
> SELECT :?port AS port_is_defined \gset
>
> However I do not think that this can be done cleanly with a "à la perl"
> defined.

The syntax is minor problem in this case - I can live with any syntax
there. I prefer a verbose syntax against not well known symbols. If I can
choose between some solutions, then my preferences are 1. some verbose
simple solution with usual syntax, 2. some syntax from another well known
product, 3. some special new PostgreSQL syntax. I don't think so :?xxx is
good idea, because for me :xxx is related to content, not to metadata and
Robert's tip of using bash syntax is more logical for me (to have syntax
for default and custom message). I understand well so it is subjective -
and more, don't think so this point is significant. We should to have this
functionality. That is all.

>
> 5. we can introduce \setexpr in psql, and \if can use pgbench expr too (the
>> result of expression) must be boolean value like now
>>
>
> Yes.
>
> 6. the psql builtin variables should be enhanced about server side and
>> client side numeric versions
>>
>
> Yes, add some typing where appropriate.
>
> 7. the psql builtin variables should be enhanced about sqlstate - we are
>> able to handle errors due setting ON_ERROR_STOP already
>>
>
> Probably.
>
> 8. the psql builtin variables can be enhanced about info about processed
>> rows
>>
>
> Yep. I've already submitted something about ROW_COUNT and such, see:
>
> https://commitfest.postgresql.org/14/1103/
>
> The pgbench can take \if command and \setexpr command (although \setexpr
>> can be redundant there, there can be nice compatibility with psql)
>>
>
> I now believe that "\let" is the nicest sounding close to set short
> option, and indeed it should be made to work for pgbench as well to keep
> things consistent, for some definition of consistent.

sounds well

Regards

Pavel

>
>
> --
> Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Erik Rijkers 2017-04-17 07:30:58 Re: Logical replication - TRAP: FailedAssertion in pgstat.c
Previous Message Fabien COELHO 2017-04-17 06:40:31 Re: pgbench - allow to store select results into variables