Hi everyone!
I've been reading tons of stuff on locale and postgresql. I am still not
in the clear about some details, though: how do system locale and
database locale work together (or not)?
(In my case, I am speaking of postgresql 8.1 on debian sarge. But
general understanding is what I am looking for.)
If I am running a database cluster with UTF8, are there any
troubles to be expected if the system locale remains "C" or somehting
like "de_AT.iso885915@euro"?
Any troubles with error messages, dumps, hacking the dump, performance?
Any trouble at all?
Is it enough to have an UTF8 locale installed on the system?
postgres@dbneu:~$ locale -a
C
de_AT.utf8@euro
does it actually have to be the system locale?
postgres@dbneu:~$ locale
LC_ALL="de_AT.UTF-8@euro"
Do multiple UTF8 system locales have any effect?
postgres@dbneu:~$ locale -a
C
de_AT.utf8@euro
en_US.utf8
Does anyone know these details? It would ease my mind. :)
Thanx in advance!
Regards
Erwin Brandstetter
(end of broadcast)
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

peter_e (AT) gmx (DOT) net wrote:
Erwin Brandstetter wrote:

>I've been reading tons of stuff on locale and postgresql. I am still
>not in the clear about some details, though: how do system locale and
>database locale work together (or not)?
>
>
The system locale is more or less ignored. What matters are the locales
set in the database.

Great!

>If I am running a database cluster with UTF8, are there
>any troubles to be expected if the system locale remains "C" or
>somehting like "de_AT.iso885915@euro"?
>
>
Your sort order will approach randomness.

()

Wait not that great! The system locale is more or less ignored, but
my sort order will approach randomness?
Can you or anyone shed some more light on this? I am even more confused
than I was before

Regards
Erwin Brandstetter

(end of broadcast)
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Erwin Brandstetter <brandstetter (AT) falter (DOT) atwrites:
Wait not that great! The system locale is more or less ignored, but
my sort order will approach randomness?

Peter's point is that a given locale setting will expect a particular
encoding, and if you try to use a different encoding then your sort
ordering will be wrong. Not "random" exactly, but not what you want.

regards, tom lane

(end of broadcast)
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

tgl (AT) sss (DOT) pgh.pa.us wrote:
Erwin Brandstetter <brandstetter (AT) falter (DOT) atwrites:

>Wait not that great! The system locale is more or less ignored, but
>my sort order will approach randomness?
>
>
Peter's point is that a given locale setting will expect a particular
encoding, and if you try to use a different encoding then your sort
ordering will be wrong. Not "random" exactly, but not what you want.

Sorry, maybe I am slow in the head. Are you referring to the system
locale of the client S?
My question was aiming at the database server S. (Maybe I have not been
clear enough myself.)

Example:

Postgresql 'de_AT.UTF-8@euro'
Server S: (Debian Sarge) set system locale 'C' (locale
'de_AT.UTF-8@euro' is installed, too)
PHP5, Apache.
Client: Browser (Mozilla Firefox in our case) on various Ss (Mac, Win,
Linux), set to work with UNICDE data.

Would the system locale of the _server_ S mess with the sort order? (
with anything at all?)

Any sorting done on the client would be based on the _client_ S system
locale, but that is a different question

Regards
Erwin Brandstetter

(end of broadcast)
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match