Tatsuo Ishii <is...@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 (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers