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: [EMAIL PROTECTED] Moscow State University Phone: 007 (095) 939 2383 Fax: 007 (095) 932 8841 http://www.sai.msu.su/~er ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
