Re: OK, that's one LOCALE bug report too many...

From: Karel Zak <zakkr(at)zf(dot)jcu(dot)cz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: OK, that's one LOCALE bug report too many...
Date: 2000-11-27 10:09:30
Message-ID: Pine.LNX.3.96.1001127101000.19331A-100000@ara.zf.jcu.cz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On Fri, 24 Nov 2000, Tom Lane wrote:

> Peter Eisentraut <peter_e(at)gmx(dot)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, int field_index);
- on-the-fly numbers (and date/time?!) recoding if BE and
FE use differend locale
- be-build index for new locale setting
- fast locale information for date/time and support for
locale-sensitive date/time parsing (IMHO almost impossible
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 ignorand FE lib. With
these problems is not possible write good large and robust FE.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2000-11-27 11:21:57 Re: [HACKERS] Indexing for geographic objects?
Previous Message Ron Chmara 2000-11-27 07:56:03 Re: Re: [NOVICE] Re: re : PHP and persistent connections