Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII
Дата
Msg-id 18204.1378736710@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> My suggestion in this matter is to disable gettext processing when
> LC_CTYPE is set to C.  We could log a warning when LC_MESSAGES is set to
> something and LC_CTYPE is set to C.  Or just do the warning and keep
> logging.  Something like that.

Meh.  Seems that would only prevent one specific instance of the general
problem that strerror can fail to translate its result.  Other locale
combinations might create the same kind of failure.

More generally, though, is strerror actually using gettext at all, or
some homegrown implementation?  As I said upthread, I would expect that
gettext("foo") returns the given ASCII string "foo" if it fails to create
a translated version.  This is evidently not what's happening in strerror.

It's way past time to look into the glibc sources and see what it's
actually doing...
        regards, tom lane



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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: ENABLE/DISABLE CONSTRAINT NAME
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII