Re: dangers of setlocale() in backend (was: problem with float8 input format) - Mailing list pgsql-hackers

From Louis-David Mitterrand
Subject Re: dangers of setlocale() in backend (was: problem with float8 input format)
Date
Msg-id 20000815175328.A10477@styx
Whole thread Raw
In response to Re: dangers of setlocale() in backend (was: problem with float8 input format)  (Karel Zak <zakkr@zf.jcu.cz>)
Responses Re: dangers of setlocale() in backend (was: problem with float8 input format)
List pgsql-hackers
On Tue, Aug 15, 2000 at 11:30:11AM +0200, Karel Zak wrote:
> 
> > But your patch sounds incredibly useful :-) Has it been integrated in
> > the mainline code yet? How does one use this functionality?
> 
>  It never will integrated into the PG standard main tree, because it is 
> stupid patch for common usege :-( (and I feel ashamed of this :-)
> 
> > Also what is the main difference with using the standard gettext call?
> > 
> >     setlocale(LC_ALL, "en_US");
> 
>  This ('LC_ALL') call load support for all locales categories (numbers,
> text, currency...etc.). Inside postgreSQL it's dangerous, because it
> change for example float numbers deciamal point..etc.

[SNIP very interesting info on PG internal locale processing]

Considering that would it then be safe to only use LC_NUMERIC and
LC_MESSAGES in setlocale() calls? The dangers Tom Lane talks about in
reference to changing locale in the backend seem to be related to
LC_COLLATE stuff, right?

Thanks for your input, cheers,

-- 
Louis-David Mitterrand - ldm@apartia.org - http://www.apartia.org

I don't build computers, I'm a cooling engineer.      -- Seymour Cray, founder of Cray Inc. 


pgsql-hackers by date:

Previous
From: Matthew Kirkwood
Date:
Subject: Re: Open Source Database Routs Competition in New Benchmark Tests
Next
From: merlin
Date:
Subject: Re: Open Source Database Routs Competition in New Benchmark Tests