Thread: locale changes

 In the atache is patch with this:

 SET LOCALE TO <value>
        Set locale to <value>, the <value> must be correct for
        current OS locale setting.

 SHOW LOCALE
        Show current locale setting for all categories.

 RESET LOCALE
        Set locale back to start-up setting.

 Now, possible is change locale environment from client without backend
restart and under one postmaster can run more backends with different
locale setting.

 All routines (formatting.c, cash.c, main.c) are correct for this change.

 BTW. --- how plan is 'money' datetype in 7.1, remove?

                     Karel

 An example:

test=# SHOW LOCALE;
NOTICE:  Locale setting: LANG=C, CTYPE=C, NUMERIC=C, TIME=C, COLLATE=C,
MONETARY=C, MESSAGES=C
SHOW VARIABLE
test=# SELECT to_char(1023.5, 'L 9999D9');
  to_char
-----------
    1023.5
(1 row)

test=# SET LOCALE TO 'de_DE';
SET VARIABLE
test=# SELECT to_char(1023.5, 'L 9999D9');
  to_char
------------
 DM  1023,5
(1 row)

test=# SET LOCALE TO 'en_US';
SET VARIABLE
test=# SELECT to_char(1023.5, 'L 9999D9');
  to_char
-----------
 $  1023.5
(1 row)

test=# RESET LOCALE;
RESET VARIABLE
test=# SELECT to_char(1023.5, 'L 9999D9');
  to_char
-----------
    1023.5
(1 row)

Karel Zak <zakkr@zf.jcu.cz> writes:
>  Now, possible is change locale environment from client without backend
> restart and under one postmaster can run more backends with different
> locale setting.

No, no, NOOOOO!!!!

This *will* destroy your database.

Think about indexes on text columns.  Change LOCALE, now the sort order
of the data is different.  Even if the btree code doesn't crash and burn
completely, it will fail to find stuff it should have found and/or
insert new items at positions that will be wrong after the next LOCALE
change.

Not only is on-the-fly LOCALE change not acceptable, but we really
ought to be recording the LOCALE settings at initdb time and forcing the
postmaster to adopt them when it starts up.  Right now you can shoot
yourself in the foot if you don't start the postmaster with the same
LOCALE every time.

Someday we may support per-column LOCALE settings, but it's not likely
ever to be safe to change LOCALE on the fly.

            regards, tom lane

On Thu, 20 Jul 2000, Tom Lane wrote:

> Karel Zak <zakkr@zf.jcu.cz> writes:
> >  Now, possible is change locale environment from client without backend
> > restart and under one postmaster can run more backends with different
> > locale setting.
>
> No, no, NOOOOO!!!!
>
> This *will* destroy your database.
>
> Think about indexes on text columns.  Change LOCALE, now the sort order

 But, it is solvable, I save original start-up setting to serarate struct
that is never changed. All routines that can allow on-the-fly locale change
can use change-able structs and index (..etc.) can use original setting.

 Now, locale (on-the-fly change-able locale) use formatting.c and money (may
be), all others routines can use start-up setting.

 For example:

    change_to_on_the_fly_locale_setting()
    to_char();
    set_original_locale();

... and SET LOCALE can be used for specific routines only.

 Comments?

 But, yes this solution is not in my patch.

                    Karel

Karel Zak <zakkr@zf.jcu.cz> writes:
>     change_to_on_the_fly_locale_setting()
>     to_char();
>     set_original_locale();

And if to_char throws an elog?

Another objection is that (if my experience with libc's
timezone-dependent code is any guide) changing the locale that much
is likely to be *slow*.  libc is designed on the assumption that you
set these things once at application startup, so it precomputes a ton
of stuff whenever you change 'em.

            regards, tom lane

On Thu, 20 Jul 2000, Tom Lane wrote:

> Karel Zak <zakkr@zf.jcu.cz> writes:
> >     change_to_on_the_fly_locale_setting()
> >     to_char();
> >     set_original_locale();
>
> And if to_char throws an elog?

 elog can check how locale struct is actual..

> Another objection is that (if my experience with libc's
> timezone-dependent code is any guide) changing the locale that much
> is likely to be *slow*.  libc is designed on the assumption that you

 It is better argument for me :-). I hope that nobody be angry at me about
this patch. I was probably really a little premature... grrr 2 programming
hours are in /dev/null..

 If I good remember, one year ago when I discussed (via private mails)
about formatting date/time with Thomas, we said something about locales
out of libc. Any system table? Any planns?

                    Karel