On Mon, 25 Jul 2016 10:43:44 -0400 Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote:
e 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? I think there are two more ways: (3 was in the Craig's message) 4. At the session startup try to reinitializie LC_MESSAGES locale category with the combination of the server (or better client-send) language and region and client-supplied encoding, and if this failed, use untranslated error message. Obvoisly, attempt to set locale to ru_RU.ISO8859-1 would fail. so, if client would ask server with ru_RU.UTF-8 default locale to use LATIN1 encoding, server would fallback to untranslated messages. This approach would have problems on windows, where locale is strictly tied to the ANSI encoding of given language/territory. Even if we would make UTF-8 a special case, attempt to connect with encoding KOI8 or LATIN5 to the Windows postgresql server which runs in Russian_Russia.1251 locale would result in the fallback to untranslated message. But I think that this case is marginal and better to present untranslated messages to the people (or applications) which require non-default 8-bit encoding even if it is possible to represent translated messages in this encoding, than to present unreadable translated messages to anybody. 5. Use transliteration in case of encoding problem. Some iconv implementations (such as Linux glibc iconv and GNU portable libiconv) supports //TRANSLIT sufix for encoding and if this suffix specified replace unrepresentable symbols with phonetically similar approximation. I don't know how well it would work for Japanese, but for Russian it is definitely better than lots of question marks. -- > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
