On Wed, 3 Dec 2003, E.Rodichev wrote:
> On Wed, 3 Dec 2003, Stephan Szabo wrote:
>
> >
> > On Wed, 3 Dec 2003, E.Rodichev wrote:
> >
> > > On Fri, 28 Nov 2003, Tom Lane wrote:
> > >
> > > > "E.Rodichev" <er@sai.msu.su> writes:
> > > > > /e:2>createdb test
> > > >
> > > > > test | er | SQL_ASCII <----- Incorrect!
> > > > > (3 rows)
> > > >
> > > > > Let's note than the last line is in fact completely incorrect.
> > > >
> > > > What's incorrect about it? You didn't ask for any other encoding
> > > > than SQL_ASCII.
> > >
> > > It is incorrect, because database "test" is, really, in KOI8, NOT in SQL_ASCII
> > > in this example, as I explained in my mail.
> >
> > No, it isn't. As far as PostgreSQL is concerned the database is SQL_ASCII
> > since you didn't override the default encoding at initdb time or at
> > createdb time. You did choose LC_ values that seem to want KOI8, but
> > locale and encoding are separate, if you want KOI8 encoding, you have to
> > say so.
>
> Yes, it is!
*sigh*
> (the first order is true for ru_RU.KOI8-R, the latter one - for C).
>
> To summarize shortly:
>
> - initdb _without_ -E flag, but with ru_RU.KOI8-R environment;
> - createdb with any environment;
> - psql indicates SQL_ASCII;
> - sorting and upper/lowercasing are in ru_RU.KOI8-R, even with LC_*
> environment is set to "C".
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?
