On Wed, 3 Dec 2003, Stephan Szabo wrote:
> The locale settings depend on LC_* at initdb time only. When the
> postmaster starts it sets the locale based on the stored values from
> initdb, not on the current environment.
>
> With an SQL_ASCII database being accessed from a client with
> client_encoding set to SQL_ASCII (which it should be if you aren't setting
> it) the byte values of a string are passed along with no conversion for
> the encoding. This means that from within one environment you should get
> back what you put in, so it might *look* like it's KOI8-R if that's what
> you're in, but it's not because someone accessing it from say an ISO8859-1
> system may see something different.
As a result, the possibility to control encodings and locales looks as
follows:
initdb createdb psql
Encoding: Y Y Y
Locale: Y N N
It seems that more natural scheme will be
initdb createdb psql
Encoding: Y Y Y
Locale: Y Y Y
Now the possibility to use different encodings for createdb and psql is
a bit strange... Also, it is impossible to have different locales
for different databases within one cluster, and it is impossible to use
different locales with one database. The latter is even more critical.
The reason is that the sorting under C locale is much more effective compared with
one under another locales (10-50 times faster for some implementations!).
Another reason is that for some applications it is _necessary_ to use different
sort order for different tables. For example, I may have two tables:
russian_persons and forein_persons, and i'd like to print the sorted list
of persons. The russian_persons names must be sorted with ru_RU.KOI8-R locale,
and the forein_persons - with C locale.
Best wishes,
E.R.
_________________________________________________________________________
Evgeny Rodichev Sternberg Astronomical Institute
email: er@sai.msu.su Moscow State University
Phone: 007 (095) 939 2383
Fax: 007 (095) 932 8841 http://www.sai.msu.su/~er
