Tom and others,
I still wonder whether I should commit this or not because this patch
does not allow none ascii column names. We know pgbench variable name
has been restricted since the functionality was born. When users
explicitly define a pgbench variable using \set, it is not a too
strong limitation, because it's in a "pgbench world" anyway and
nothing is related to PostgreSQL core specs. However, \gset is not
happy with perfectly valid column names in PostgreSQL core, which
looks too inconsistent and confusing for users.
So the choices are:
1) commit the patch now with documenting the limitation. (the patch looks good to me except the issue above)
2) move it to next cf hoping that someone starts the implementation to
eliminate the limitation of none ascii variable names.
Comments?
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
> Hello Tatsuo-san,
>
>> It seems the new feature \gset doesn't work with tables having none
>> ascii column names:
>
> Indeed. The same error is triggered with the \set syntax, which does
> not involve any query execution.
>
> I have added a sentence mentionning the restriction when variables are
> first discussed in the documentation, see attached patch.
>
> --
> Fabien.