pgbench: extend variable usage in scripts

From: Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>
To: Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: pgbench: extend variable usage in scripts
Date: 2025-08-29 07:23:07
Message-ID: 20250829162307.b2888293e1cf809668333395@sraoss.co.jp
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

I would like to propose patches to extend variable usage in pgbench scripts.

* 0001: Allow variables to be used as an SQL literal or identifier

Currently, variables in pgbench scripts are expanded always without
quotes, so they cannot be used as SQL literals or identifiers.
This patch allows the use of :'var' and :"var" in addition to :var

However, they can used only in SQL commands, not in the arguments of
meta-commands, since exprscan.l (the lexical scanner for pgbench backslash
commands) cannot currently handle quoted values.

Also, we have to use \aset, \gset or -D option to assign a string to a varialbe,
since pgbench's \set command cannot recognize text values in its arguments.

* 0002: Add syntax for variable exisitence check

Currently, pgbench does not support :{?var} syntax to check whether the variable
is defined or not. This patch adds support for this syntax in meta-command arguments.
This is useful for checking if \aset set the result to the variable or not.

However, it cannot be used in SQL statements for now.

Some of the current limitations described above might be relaxed in the future, but
for now, I would like to ask for initial feedback on this proposal.

Regards,
Yugo Nagata

--
Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>

Attachment Content-Type Size
0002-pgbench-Add-syntax-for-variable-exisitence-check.patch text/x-diff 2.2 KB
0001-pgbench-Allow-variables-to-be-used-as-an-SQL-literal.patch text/x-diff 4.9 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2025-08-29 07:25:47 Re: Assert single row returning SQL-standard functions
Previous Message Chao Li 2025-08-29 07:22:04 Re: SQL:2023 JSON simplified accessor support