Re: Encoding problem with 7.4

E.Rodichev wrote:

>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.
>

see Multi-Language Support section on TODO list at 
http://developer.postgresql.org/todo.php - note that this specifies 
per-column locales rather than per-table, which should be even more useful.

Most of these items have no names against them, meaning you could work 
on them ...

cheers

andrew