| From: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
|---|---|
| To: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: current breakage with PGCLIENTENCODING |
| Date: | 2003-04-27 10:08:07 |
| Message-ID: | 20030427.190807.104042312.t-ishii@sra.co.jp |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2003-04-27 15:14:39 | Re: current breakage with PGCLIENTENCODING |
| Previous Message | Sean Chittenden | 2003-04-27 08:35:11 | Re: [EXAMPLE] Overly zealous security of schemas... |