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
Subject: Re: pgbench - allow to store select results into variables
In-reply-to: <20170406.090710.2057011852302352812.t-ishii@sraoss.co.jp>
References: 
 <CAOGQiiOsSDqq0LAqw+=bWtZK+N4-XBjx-_d+ijwax823+ftAYQ@mail.gmail.com>
 <20170405.094548.1184280384967203518.t-ishii@sraoss.co.jp>
 <alpine.DEB.2.20.1704052019100.1967@lancre>
 <20170406.090710.2057011852302352812.t-ishii@sraoss.co.jp>
Comments: In-reply-to Tatsuo Ishii <ishii@sraoss.co.jp>
	message dated "Thu, 06 Apr 2017 09:07:10 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7545.1491438259.1@sss.pgh.pa.us>
Date: Wed, 05 Apr 2017 20:24:19 -0400
Message-ID: <7546.1491438259@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers