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.1000816074046.32589A-100000@ara.zf.jcu.cz обсуждение исходный текст |
Ответ на | Re: dangers of setlocale() in backend (was: problem with float8 input format) (Louis-David Mitterrand <cunctator@apartia.ch>) |
Список | pgsql-hackers |
On Tue, 15 Aug 2000, Louis-David Mitterrand wrote: > [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? Not sure that use the LC_NUMERIC is correct. For example next routine is inside PG: Datum float4out(PG_FUNCTION_ARGS) { float4 num = PG_GETARG_FLOAT4(0); char *ascii = (char *) palloc(MAXFLOATWIDTH + 1); sprintf(ascii, "%.*g", FLT_DIG, num); PG_RETURN_CSTRING(ascii); } What happen here with/without LC_NUMERIC? type 'man sprintf': For some numeric conversion a radic character (Decimal point') or thousands' grouping character is used. The actual character used depends on the LC_NUMERIC part of ^^^^^^^^^^^ the locale. The POSIX locale uses .' as radix character, and does not have a grouping character. Thus, printf("%'.2f", 1234567.89); results in {4567.89' in the POSIX locale, in {4567,89'in the nl_NL locale, and in 234.567,89' in the da_DK locale. Very simular it's in the float4in() with strtod() ...etc. Karel
В списке pgsql-hackers по дате отправления: