Re: pgbench - allow to store select results into variables
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tatsuo Ishii <ishii@sraoss.co.jp>
Cc: 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:24:19Z
Lists: pgsql-hackers
Tatsuo Ishii <ishii@sraoss.co.jp> writes: > I still wonder whether I should commit this or not because this patch > does not allow none ascii column names. 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. 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. regards, tom lane
Commits
-
pgbench: Remove \cset
- 25ee70511ec2 12.0 landed
-
pgbench: add \cset and \gset commands
- 6260cc550b0e 12.0 landed
-
Adjust pgbench to allow non-ASCII characters in variable names.
- 9d36a386608d 11.0 landed
-
Refactor script execution state machine in pgbench.
- 12788ae49e19 10.0 cited
-
Allow empty queries in pgbench.
- 6471045230f5 10.0 cited