Обсуждение: PL/pgSQL does not accept none ASCII identifiers

It seems PL/pgSQL accepts only ASCII identifiers. This results in
column names of Europian or Asian languages are syntax errors for
example. Fix for this looks simple (see attached patches) but I would
like to know if there's any intentional reasons for this.
--
Tatsuo Ishii

*** scan.l~    Thu May 27 05:55:06 1999
--- scan.l    Thu Sep  7 19:25:36 2000
***************
*** 48,55 **** #define YY_INPUT(buf,res,max)    plpgsql_input(buf, &res, max) %} 
! WS    [[:alpha:]_"]
! WC    [[:alnum:]_"]  %x    IN_STRING IN_COMMENT 
--- 48,55 ---- #define YY_INPUT(buf,res,max)    plpgsql_input(buf, &res, max) %} 
! WS    [\200-\377_A-Za-z"]
! WC    [\200-\377_A-Za-z0-9"]  %x    IN_STRING IN_COMMENT 

Tatsuo Ishii wrote:
> It seems PL/pgSQL accepts only ASCII identifiers. This results in
> column names of Europian or Asian languages are syntax errors for
> example. Fix for this looks simple (see attached patches) but I would
> like to know if there's any intentional reasons for this.
   No  other  reason  than  that  I  just forgot about non-ascii   identifiers when I coded that (long long ago). Go
ahead and   change it.
 


Jan

> --
> Tatsuo Ishii
>
> *** scan.l~  Thu May 27 05:55:06 1999
> --- scan.l   Thu Sep  7 19:25:36 2000
> ***************
> *** 48,55 ****
>   #define YY_INPUT(buf,res,max)  plpgsql_input(buf, &res, max)
>   %}
>
> ! WS    [[:alpha:]_"]
> ! WC    [[:alnum:]_"]
>
>   %x    IN_STRING IN_COMMENT
>
> --- 48,55 ----
>   #define YY_INPUT(buf,res,max)  plpgsql_input(buf, &res, max)
>   %}
>
> ! WS    [\200-\377_A-Za-z"]
> ! WC    [\200-\377_A-Za-z0-9"]
>
>   %x    IN_STRING IN_COMMENT


--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #

> > It seems PL/pgSQL accepts only ASCII identifiers. This results in
> > column names of Europian or Asian languages are syntax errors for
> > example. Fix for this looks simple (see attached patches) but I would
> > like to know if there's any intentional reasons for this.
> 
>     No  other  reason  than  that  I  just forgot about non-ascii
>     identifiers when I coded that (long long ago). Go  ahead  and
>     change it.
> 
> 
> Jan

Ok, I'll go ahead and commit the changes into the current and stable
tree.
--
Tatsuo Ishii