Re: pgbench - allow to store select results into variables

Tatsuo Ishii <ishii@sraoss.co.jp>

From: Tatsuo Ishii <ishii@sraoss.co.jp>
To: tgl@sss.pgh.pa.us
Cc: ishii@sraoss.co.jp, coelho@cri.ensmp.fr, rafia.sabih@enterprisedb.com, michael.paquier@gmail.com, Langote_Amit_f8@lab.ntt.co.jp, robertmhaas@gmail.com, pavel.stehule@gmail.com, pgsql-hackers@postgresql.org
Date: 2017-04-06T00:36:50Z
Lists: pgsql-hackers
> Well, personally, as an all-ASCII guy I'm not too fussed about that,
> but I can see that other people might be annoyed.
> 
> The main problem in dealing with it seems to be whether you're willing
> to support pgbench running in non-backend-safe encodings (eg SJIS).
> If we rejected that case then it'd be a relatively simple change to allow
> pgbench to treat any high-bit-set byte as a valid variable name character.
> (I think anyway, haven't checked the code.)
> 
> Although ... actually, psql allows any high-bit-set byte in variable
> names (cf valid_variable_name()) without concern about encoding.
> That means it's formally incorrect in SJIS, but it's been like that
> for an awful lot of years and nobody's complained.  Maybe it'd be fine
> for pgbench to act the same.

That's my thought too.

> Having said all that, I think we're at the point in the commitfest
> where if there's any design question at all about a patch, it should
> get booted to the next cycle.  We are going to have more than enough
> to do to stabilize what's already committed, we don't need to be
> adding more uncertainty.

Ok, I will move the patch to the next cf.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp


Commits

  1. pgbench: Remove \cset

  2. pgbench: add \cset and \gset commands

  3. Adjust pgbench to allow non-ASCII characters in variable names.

  4. Refactor script execution state machine in pgbench.

  5. Allow empty queries in pgbench.