Hello Tatsuo-san,
>>> If I understand correctly, the patch is moved because of the unrelated
>>> issue that variables cannot be utf8 in pgbench, and it is a condition
>>> to consider this patch that existing pgbench variables (set with \set)
>>> can be utf8?
>>
>> I'm not sure if it is "unrelated" because the new feature relies on
>> existing pgbench variable infrastructure.
>
> Sure. I meant that the constraint on variable names exists before the patch
> and the patch is not related to variable names, but the patch is about
> variables, obviously.
>
> As "psql" variables can be utf8 and that the same scanner is used, but the
> variables values are not stritcly the same (they are typed in pgbench), I'm
> wondering whether the effort should be do share more code/abstraction between
> psql & pgbench or just adjust/replicate the needed small functions/code
> excerpts.
As the variable infrastructures are pretty different between psql &
pgbench (typed vs untyped values, sorted array vs linked list data
structure, no hook vs 2 hooks, name spaces vs no such thing...), I have
chosen the simplest option of just copying the name checking function and
extending the lexer to authorize non-ascii letters, so that psql/pgbench
would accept the same variable names with the same constraint about
encodings.
See patch attached & test script.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
