Hi all In the wire protocol, currently if you get an error from the server before you know it's processed your startup packet successfully you don't know what character encoding that error is in.
If the error came from the postmaster then it's in the system's default encoding or whatever locale the postmaster was started under. If the error came from the DB backend it's in the DB backend's default encoding, switched to during backend startup. Assuming it got that far. If the error came after client_encoding was applied, it's in your requested client_encoding. This leaves the client unable to reliably interpret error messages. The 4.1 protocol should probably explicitly signal the encoding in the first message from the server, and thereafter whenever it changes. (This is somewhat related to the mess we make of text encodings in the log files, where the postmaster writes in one encoding and DB backends write in another). Example psql session, in a terminal with en_AU.UTF-8 locale, connecting to a postmaster started with: $ LC_ALL=ru_RU.ISO-8859-5 LANG=ru_RU.ISO-8859-5 PATH=$HOME/pg/pg94/bin postgres -D pg94_ru -p 9595 $ locale LANG=en_AU.UTF-8 LC_CTYPE="en_AU.UTF-8" ... LC_ALL= $ psql -p 9595 psql: �����: ���� ������ "craig" �� ���������� $ psql -q -p 9595 postgres postgres=# \c nosuch �����: ���� ������ "nosuch" �� ���������� Previous connection kept postgres=# select indb_error(); ОШИБКА: функция indb_error() не существует LINE 1: select indb_error(); ^ HINT: Функция с данными именем и типами аргументов не найдена. Возможно, вам следует добавить явные преобразования типов. Note the garbage where psql happily dumps an ISO-8859-5 message to the terminal because it has no way of knowing it isn't in the current client_encoding, and no way of telling what encoding it is anyway. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers