Re: pgbench - allow to store select results into variables

From: Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>
To: rafia(dot)sabih(at)enterprisedb(dot)com
Cc: coelho(at)cri(dot)ensmp(dot)fr, michael(dot)paquier(at)gmail(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp, robertmhaas(at)gmail(dot)com, pavel(dot)stehule(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pgbench - allow to store select results into variables
Date: 2017-04-05 00:45:48
Message-ID: 20170405.094548.1184280384967203518.t-ishii@sraoss.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>> Please find attached a v8 which hopefully fixes these two issues.
> Looks good to me, marking as ready for committer.

I have looked into this a little bit.

It seems the new feature \gset doesn't work with tables having none
ascii column names:

$ src/bin/pgbench/pgbench -t 1 -f /tmp/f test
starting vacuum...end.
gset: invalid variable name: "数字"
client 0 file 0 command 0 compound 0: error storing into var 数字
transaction type: /tmp/f
scaling factor: 1
query mode: simple
number of clients: 1
number of threads: 1
number of transactions per client: 1
number of transactions actually processed: 0/1

This is because pgbench variable names are limited to ascii
ranges. IMO the limitation is unnecessary and should be removed. (I
know that the limitation was brought in by someone long time ago and
the patch author is not responsible for that).

Anyway, now that the feature reveals the undocumented limitation, we
should document the limitation of \gset at least.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2017-04-05 01:05:19 Re: Statement timeout behavior in extended queries
Previous Message Michael Paquier 2017-04-05 00:29:27 Re: [PATCH] Reduce src/test/recovery verbosity