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)
|
Список | 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 по дате отправления: