On Mon, 25 Jul 2016 10:43:44 -0400 Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote:
> 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. Really, situation is a bit worse. There is at least one case, where error message comes unreadble to the client, even if encodings are compatible. I.e. if server default locale is ru_RU.UTF-8 and client requestes encoding WIN1251 which is able to handle cyrillic. If error occurs during processing of StartMessage protocol message, i.e. client request connection to unexisting database, ErrorResponse would contain message in the server default locale, despite of client encoding being specified in the StartMessage. If session is correctly established with such parameters, error messages are displayed correctly. I haven't yet investigatged if it is just delayed initialization of backend locale system or backend is not yet forked at the time of generation of this message and wrongly encoded message is sent by postmaster. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
