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)
Thu, 20 Jul 2000 14:18:59 +0200 (CEST)
Karel Zak <zakkr@zf.jcu.cz>
locale changes
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

Thu, 20 Jul 2000 11:16:23 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: locale changes 

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		





Thu, 20 Jul 2000 17:31:01 +0200 (CEST)
Karel Zak <zakkr@zf.jcu.cz>
Re: locale changes 
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

Thu, 20 Jul 2000 11:48:52 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: locale changes 

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


Thu, 20 Jul 2000 18:16:15 +0200 (CEST)
Karel Zak <zakkr@zf.jcu.cz>
Re: locale changes 
Karel Zak writes:

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

I don't think that locale should be a session parameter ever. The locale
information is naturally associated with the stored data (i.e., what
language is the text). If you're talking about currency display then it's
even worse, unless you're proposing on the fly conversion.


-- 
Peter Eisentraut                  Sernanders vï¿½g 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


Fri, 21 Jul 2000 02:46:10 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: [PATCHES] locale changes 