Re: pgbench - allow to store select results into variables - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pgbench - allow to store select results into variables
Date
Msg-id 7546.1491438259@sss.pgh.pa.us
Whole thread Raw
In response to Re: pgbench - allow to store select results into variables  (Rafia Sabih <rafia.sabih@enterprisedb.com>)
Responses Re: pgbench - allow to store select results into variables  (Andres Freund <andres@anarazel.de>)
Re: pgbench - allow to store select results intovariables  (Tatsuo Ishii <ishii@sraoss.co.jp>)
List 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



pgsql-hackers by date:

Previous
From: Neha Khatri
Date:
Subject: Re: strange parallel query behavior after OOM crashes
Next
From: Andres Freund
Date:
Subject: Re: pgbench - allow to store select results into variables