Example: I have a database cluster initialized with --locale=ru_RU.UTF-8
(built with NLS). Let's say for some reason, I have client encoding set
to LATIN1. All error messages come back like this:
test=> select * from notthere;
ERROR: character with byte sequence 0xd0 0x9e in encoding "UTF8" has no
equivalent in encoding "LATIN1"
There is no straightforward way for the client to learn that there is a
real error message, but it could not be converted.
I think ideally we could make this better in two ways:
1) Send the original error message untranslated. That would require
saving the original error message in errmsg(), errdetail(), etc. That
would be a lot of work for only the occasional use. But it would also
facilitate an occasionally-requested feature of writing untranslated
error messages into the server log or the csv log, while sending
translated messages to the client (or some variant thereof).
2) Send an indication that there was an encoding problem. Maybe a
NOTICE, or an error context? Wiring all this into elog.c looks a bit
tricky, however.
Ideas?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
