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