Re: PGCLIENTENCODING behavior of current CVS source
От | Tom Lane |
---|---|
Тема | Re: PGCLIENTENCODING behavior of current CVS source |
Дата | |
Msg-id | 18777.1100617917@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | PGCLIENTENCODING behavior of current CVS source (Weiping <laser@qmail.zhengmai.net.cn>) |
Ответы |
Re: PGCLIENTENCODING behavior of current CVS source
Re: PGCLIENTENCODING behavior of current CVS source |
Список | pgsql-general |
Weiping <laser@qmail.zhengmai.net.cn> writes: > [ database encoding is unicode ] > now I can login, but when I do a: > DHY_JJG=# \dt > ERROR: invalid byte sequence for encoding "UNICODE": 0xed > but, after: > DHY_JJG=# \encoding gbk > DHY_JJG=#\dt > woule be ok. This is a risk no matter what encoding is used in the client-side .po files; as long as it's different from the current client_encoding, there is a potential for mis-conversion and other problems. I don't see a simple solution. In this particular case, it would help if psql's describe commands didn't assume they could send localized column headers to the server --- but I don't think that solves all related issues. BTW, Peter, it seems like this may be a good argument for keeping the client and server .po files separate. They might need different encodings. regards, tom lane
В списке pgsql-general по дате отправления: