On Tue, Aug 15, 2000 at 09:23:15AM +0200, Karel Zak wrote:
> > Thank for the pointer to these functions, which are indeed convenient.
> > But the problem remains of not being able to change the backend's locale
> > on-the-fly. For example if an auction user is spanish and the next one
> > is german the locale needs to change several times during the life of
> > the DB, which raises some larger index-related issues apparently.
>
>  Before some weeks ago I sent to -patches list patch that allows to change
> locales on-the-fly via 'SET LOCALE' command. But as say Tom L. it's
> VERY DANGEROUS. Solution is locales per columns or something like this, but
> nobody works on this :-)

But your patch sounds incredibly useful :-) Has it been integrated in
the mainline code yet? How does one use this functionality?

Also what is the main difference with using the standard gettext call?

	setlocale(LC_ALL, "en_US");

Thanks,

--
Louis-David Mitterrand - ldm@apartia.org - http://www.apartia.org

Tue, 15 Aug 2000 11:14:52 +0200
Louis-David Mitterrand <cunctator@apartia.ch>
Re: dangers of setlocale() in backend (was: problem with float8 input
	format)

> 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


Tue, 15 Aug 2000 11:30:11 +0200 (CEST)
Karel Zak <zakkr@zf.jcu.cz>
Re: dangers of setlocale() in backend (was: problem with float8 input
	format)
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. 

Tue, 15 Aug 2000 17:53:28 +0200
Louis-David Mitterrand <cunctator@apartia.ch>
Re: dangers of setlocale() in backend (was: problem with float8 input
	format)

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


 


Wed, 16 Aug 2000 07:51:05 +0200 (CEST)
Karel Zak <zakkr@zf.jcu.cz>
Re: dangers of setlocale() in backend (was: problem with float8 input
	format)