Re: dangers of setlocale() in backend (was: problem with float8 input format)

Поиск
Список
Период
Сортировка
От Louis-David Mitterrand
Тема Re: dangers of setlocale() in backend (was: problem with float8 input format)
Дата
Msg-id 20000815175328.A10477@styx
обсуждение исходный текст
Ответ на Re: dangers of setlocale() in backend (was: problem with float8 input format)  (Karel Zak <zakkr@zf.jcu.cz>)
Ответы Re: dangers of setlocale() in backend (was: problem with float8 input format)  (Karel Zak <zakkr@zf.jcu.cz>)
Список 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 по дате отправления:

Предыдущее
От: Matthew Kirkwood
Дата:
Сообщение: Re: Open Source Database Routs Competition in New Benchmark Tests
Следующее
От: merlin
Дата:
Сообщение: Re: Open Source Database Routs Competition in New Benchmark Tests