handling unconvertible error messages

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема handling unconvertible error messages
Дата
Msg-id bd579724-86f7-615b-fce8-8073731eef97@2ndquadrant.com
обсуждение исходный текст
Ответы Re: handling unconvertible error messages  (Craig Ringer <craig@2ndquadrant.com>)
Re: handling unconvertible error messages  (Victor Wagner <vitus@wagner.pp.ru>)
Re: handling unconvertible error messages  (Victor Wagner <vitus@wagner.pp.ru>)
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: No longer possible to query catalogs for index capabilities?
Следующее
От: Andrew Gierth
Дата:
Сообщение: Re: No longer possible to query catalogs for index capabilities?