Skip site navigation (1) Skip section navigation (2)

Re: Turkish downcasting in PL/pgSQL

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, ntufar <ntufar(at)pisem(dot)net>
Cc: pgsql-bugs(at)postgresql(dot)org, devrim(at)tdmsoft(dot)com
Subject: Re: Turkish downcasting in PL/pgSQL
Date: 2004-08-14 08:21:33
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugspgsql-hackers
Tom Lane wrote:
> 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?

You'd have to set LC_ALL=C to be really sure to override everything.  
But I would stay away from doing that globally, because all the 
translation work in gcc and make would go to waste.

I would also suggest that Nicolai report this issue to the flex 
developers.  It's only bound to reappear everywhere case-insensitive 
flex scanners are used.

Peter Eisentraut

In response to


pgsql-hackers by date

Next:From: Gaetano MendolaDate: 2004-08-14 08:28:11
Subject: Re: Calling PL functions with named parameters
Previous:From: Gaetano MendolaDate: 2004-08-14 08:16:27
Subject: Re: Calling PL functions with named parameters

pgsql-bugs by date

Next:From: Peter EisentrautDate: 2004-08-14 08:34:38
Subject: Re: Turkish downcasting in PL/pgSQL
Previous:From: Tom LaneDate: 2004-08-14 02:50:26
Subject: Re: Primary key duplicates

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group