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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
