Re: Encoding problem with 7.4

On Wed, 3 Dec 2003, Stephan Szabo wrote:

> Only the locale settings at initdb time matter. Changing the LC_* later
> is not going to change what the database does. Encoding and locale are
> separate (but related) and it is your responsibility to make sure the
> choices are consistent. If you do not specify an encoding, SQL_ASCII is
> used for the encoding. If the characters happen to line up appropriately
> for what your ru_RU.KOI8-R locale expects it'll even happen to appear to
> work for sorting and case changes (and things like isprint). Which part of
> this are you not understanding?

Thank you, it is much more consistent answer. But again, the things are
going not exactly the way you wrote.

From your opinion the chain is

data -> encoding transform -> locale transform -> output

It looks clean and reasonable.

Encoding transform may be set during initdb or createdb (is it true?)

But when locale transform is defined? In general unix flavor it should
depend on LC_* setting (is it true?)

As I described in my first posting the situation is different. Namely,
locale setting now defines _encoding transform_ (and data representation
in storage), but _locale transform_ doesnt depend on LC_*.

Best wishes,
E.R.

_________________________________________________________________________
Evgeny Rodichev Sternberg Astronomical Institute
email: er(at)sai(dot)msu(dot)su Moscow State University
Phone: 007 (095) 939 2383
Fax: 007 (095) 932 8841 http://www.sai.msu.su/~er