Re: dangers of setlocale() in backend (was: problem with float8 input format)
От | Karel Zak |
---|---|
Тема | Re: dangers of setlocale() in backend (was: problem with float8 input format) |
Дата | |
Msg-id | Pine.LNX.3.96.1000815105622.15203D-100000@ara.zf.jcu.cz обсуждение исходный текст |
Ответ на | Re: dangers of setlocale() in backend (was: problem with float8 input format) (Louis-David Mitterrand <cunctator@apartia.ch>) |
Ответы |
Re: dangers of setlocale() in backend (was: problem with float8 input format)
|
Список | pgsql-hackers |
> 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. In the PostgreSQL are used (only): setlocale(LC_CTYPE, ""); setlocale(LC_COLLATE, ""); setlocale(LC_MONETARY, ""); For more information see the file ustils/adt/pg_locale.c in PG sources, that allows you to change and load *all* locales catg. and set it back to previous state. It is used for to_char() that needs load LC_NUMERIC informations. But again: after your functions you must always set correct locales. And in 7.1 it will more important, because CurrentLocaleConv struct in pg_locale.c that use to_char() is load only once --- it's performance option. And not is a way how this struct change if it's already filled, because we not expect on-the-fly locales.... Karel
В списке pgsql-hackers по дате отправления: