Re: current breakage with PGCLIENTENCODING - Mailing list pgsql-hackers

From Tatsuo Ishii
Subject Re: current breakage with PGCLIENTENCODING
Date
Msg-id 20030427.190807.104042312.t-ishii@sra.co.jp
Whole thread Raw
In response to Re: current breakage with PGCLIENTENCODING  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: current breakage with PGCLIENTENCODING  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: current breakage with PGCLIENTENCODING  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: current breakage with PGCLIENTENCODING  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> > I would not have been real surprised to hear that psql's \encoding is
> > out of sync, but it *does* surprise me that "show client_encoding" might
> > not match pg_client_encoding().  I would think those are looking at the
> > same backend state variable.  Any theory how that could happen?
> 
> It occurs to me that the CVS-tip code tries to set client_encoding much
> earlier in backend startup than was the case when this was driven by
> a SET command issued by libpq after backend startup completed.  However,
> it works fine for me.  Why isn't it working for you?

I guess that's because your database encoding is SQL_ASCII. Could you
try with an EUC_JP encoded database?
--
Tatsuo Ishii



pgsql-hackers by date:

Previous
From: Sean Chittenden
Date:
Subject: Re: [EXAMPLE] Overly zealous security of schemas...
Next
From: Tom Lane
Date:
Subject: Re: current breakage with PGCLIENTENCODING