Re: pgbench - allow to store select results into variables

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>
Cc: coelho(at)cri(dot)ensmp(dot)fr, rafia(dot)sabih(at)enterprisedb(dot)com, michael(dot)paquier(at)gmail(dot)com, 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-06 00:24:19
Message-ID: 7546.1491438259@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2017-04-06 00:28:24 Re: pgbench - allow to store select results into variables
Previous Message Neha Khatri 2017-04-06 00:17:17 Re: strange parallel query behavior after OOM crashes