Re: current breakage with PGCLIENTENCODING
От | Tatsuo Ishii |
---|---|
Тема | Re: current breakage with PGCLIENTENCODING |
Дата | |
Msg-id | 20030427.190807.104042312.t-ishii@sra.co.jp обсуждение исходный текст |
Ответ на | Re: current breakage with PGCLIENTENCODING (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: current breakage with PGCLIENTENCODING
Re: current breakage with PGCLIENTENCODING Re: current breakage with PGCLIENTENCODING |
Список | 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 по дате отправления: