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  (guenter strubinsky <strubinsky@acm.org>)
Re: PGCLIENTENCODING behavior of current CVS source  (Peter Eisentraut <peter_e@gmx.net>)
Список 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 по дате отправления:

Предыдущее
От: "Mike Cox"
Дата:
Сообщение: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Следующее
От: Mage
Дата:
Сообщение: out of disk space