Re: Turkish downcasting in PL/pgSQL - Mailing list pgsql-bugs

From ntufar
Subject Re: Turkish downcasting in PL/pgSQL
Date
Msg-id 1092337751.2945.16.camel@localhost
Whole thread Raw
In response to Re: Turkish downcasting in PL/pgSQL  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
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


Attachment

pgsql-bugs by date:

Previous
From: ntufar
Date:
Subject: Re: Turkish downcasting in PL/pgSQL
Next
From: Tom Lane
Date:
Subject: Re: BUG #1216: pgcrypto:hmac() segfaults