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

From Tom Lane
Subject Re: Turkish downcasting in PL/pgSQL
Date
Msg-id 29209.1092324761@sss.pgh.pa.us
Whole thread Raw
In response to Turkish downcasting in PL/pgSQL  (ntufar <ntufar@pisem.net>)
Responses Re: Turkish downcasting in PL/pgSQL  (ntufar <ntufar@pisem.net>)
Re: Turkish downcasting in PL/pgSQL  (Peter Eisentraut <peter_e@gmx.net>)
Re: Turkish downcasting in PL/pgSQL  (Devrim GUNDUZ <devrim@gunduz.org>)
List pgsql-bugs
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.

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

pgsql-bugs by date:

Previous
From: Kris Jurka
Date:
Subject: Re: Notifications in JDBC driver not correct for V3 protocol
Next
From: Tom Lane
Date:
Subject: Re: Turkish downcasting in PL/pgSQL