handling unconvertible error messages

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: handling unconvertible error messages
Date: 2016-07-25 14:43:44
Message-ID: bd579724-86f7-615b-fce8-8073731eef97@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Gierth 2016-07-25 15:02:23 Re: No longer possible to query catalogs for index capabilities?
Previous Message Tom Lane 2016-07-25 14:35:17 Re: No longer possible to query catalogs for index capabilities?