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

From Pavel Stehule
Subject Re: [HACKERS] Variable substitution in psql backtick expansion
Date
Msg-id CAFj8pRBiHg49uFdQEkAKG0bO1o7TgZJcJc26_kzQT00ZdS2xyg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Variable substitution in psql backtick expansion  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: [HACKERS] Variable substitution in psql backtick expansion  (Fabien COELHO <coelho@cri.ensmp.fr>)
List 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.

pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: [HACKERS] pgbench - allow to store select results intovariables
Next
From: Erik Rijkers
Date:
Subject: Re: [HACKERS] Logical replication - TRAP: FailedAssertion in pgstat.c