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

From: Karel Zak <zakkr(at)zf(dot)jcu(dot)cz>
To: ldm(at)apartia(dot)ch
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: dangers of setlocale() in backend (was: problem with float8 input format)
Date: 2000-08-16 05:51:05
Message-ID: Pine.LNX.3.96.1000816074046.32589A-100000@ara.zf.jcu.cz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Lockhart 2000-08-16 06:56:13 Re: MySQL disputes benchmarks..
Previous Message Philip Warner 2000-08-16 04:35:04 Re: Security choices...