Re: Encoding problem with 7.4

From: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
To: "E(dot)Rodichev" <er(at)sai(dot)msu(dot)su>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Encoding problem with 7.4
Date: 2003-12-04 15:46:11
Message-ID: 20031204073747.U66123@megazone.bigpanda.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On Thu, 4 Dec 2003, 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

As a note you can change the *client* encoding from psql, not the *server*
encoding. They're also two separate notions.

Andrew already commented on the TODO list. You may also wish to look
through the archives for a recent message from Peter E on the subject as
he was looking into starting towards multiple collations and such.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jack Coates 2003-12-04 16:06:23 tuning questions
Previous Message phd9110 2003-12-04 15:45:23 Does Catalog contain the information of index insert/update/delete tuples number ??