Re: OK, that's one LOCALE bug report too many... - Mailing list pgsql-hackers

On Fri, 24 Nov 2000, Tom Lane wrote:

> Peter Eisentraut <peter_e@gmx.net> writes:
> > Tom Lane writes:
> >> I propose, therefore, that in an --enable-locale installation, initdb
> >> should save its values for LC_COLLATE and LC_CTYPE in pg_control, and
> >> backend startup should restore these settings from pg_control.
> 
> > Note that when these are unset there might still be a "catch-all" locale
> > value coming from the LANG env. var. (or LC_ALL on some systems).
> 
> Actually, what I intend to do while writing pg_control is read the
> current effective values via "setlocale(category, NULL)" --- then it
> shouldn't matter where they came from, no?
> 
> This brings up a question I had just come across while doing further
> research: backend/main/main.c does 
> 
> #ifdef USE_LOCALE
>     setlocale(LC_CTYPE, "");    /* take locale information from an
>                                  * environment */
>     setlocale(LC_COLLATE, "");
>     setlocale(LC_MONETARY, "");
> #endif
> 
> which seems a little odd --- why not setlocale(LC_ALL, "") ?  Karel
> Zak said in a thread around 8/15/00 that this is deliberate, but
> I don't quite see why.
LC_ALL set too:
LC_NUMERIC and LC_TIME
we in backend use some locale sensitive routines like strftime() and
sprintf() (and more?).
The timeofday() make output via strftime() if you set LC_ALL, a query 
like:select timeofday()::timestamp;

will (IMHO) crashed.
With float numbers and decimal point I not sure. If *all* numbers will
like locale-setting and all routines and utils will expect correct
locale-like decimal point we probably not see some problem. But what
will happen in client program if this FE not will known anything about
current BE setting? BE send locale decimal point (czech) "123,456" and
and FE is set to "en_US" - event of client's atod() is "123.000"....
And etc...etc...
We need *robust* BE<->FE correct and comumns specific local supporte, 
without this we can use locale sensitive to_char() for numbers and pray 
and hope that everything in the PG is right :-)
we need (TODO?):
- comumns specific locale setting- FE routine for obtain column locale setting, like    PQflocale(const PGresult *res,
intfield_index);- on-the-fly numbers (and date/time?!) recoding if BE and  FE use differend locale- be-build index for
newlocale setting- fast locale information for date/time and support for  locale-sensitive date/time parsing (IMHO
almostimpossible  write this)... etc.
 
too much long way to LC_ALL.
                Karel

PS. IMHO current PG locale setting is not bad. I know biger problems   an example not-existing error codes and thread
ignorandFE lib. With   these problems is not possible write good large and robust FE.