Re: Turkish downcasting in PL/pgSQL

ntufar <ntufar@pisem.net>

From: ntufar <ntufar@pisem.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-bugs@postgresql.org
Date: 2004-08-12T19:09:11Z
Lists: pgsql-bugs, pgsql-hackers

Attachments

Greetings,


12-08-2004 Perşembe günü saat 18:32 sularında, Tom Lane dedi ki:
ntufar <ntufar@pisem.net> writes:
> > flex (flex version 2.5.4) incorporates case-insensitivity in it's
> > state tables because if I run flex stage with LANG=C everything
> > works fine.
>
> Ick.  That is of course why it worked for me when I tested it :-(
>
> > A quick and dirty fix could be implemented by placing
> >      LANG=C
> >      export LANG
> > in file src/pl/plpgsql/src/Makefile before calling flex.
>
> This is probably what we'd better do.  Otherwise we have
> build-context-dependency in the system's behavior, which is bad.
>
I attached a diff of fix that adds LANG=C; before call to $(FLEX).
Fixes the problem here but I don't know if adding environment variable
assignment like this is appropriate. I am not too fluent in PostgreSQL
build environment and do not know where one can put a global deffinition
you are talking below.

Peter, any thoughts on this one way or the other?  At the moment
> plpgsql's scan.l seems to be the only use of '%option
case-insensitive'
> but we have enough flex lexers laying about that I wouldn't be
surprised
> to have this same risk elsewhere.  Is it reasonable to try to force
> LANG=C in some global fashion during the build?
>
>                       regards, tom lane
>
Best regards,
Nicolai Tufar