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

Поиск
Список
Период
Сортировка
От MauMau
Тема Re: [bug fix] strerror() returns ??? in a UTF-8/C database withLC_MESSAGES=non-ASCII
Дата
Msg-id 2EA0B1A05B764781AD94C7124ECDEE33@maumau
обсуждение исходный текст
Ответ на Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII  (Noah Misch <noah@leadboat.com>)
Список pgsql-hackers
From: "Noah Misch" <noah@leadboat.com>
> I like (2), at least at a high level.  The concept of errno_str.patch is 
> safe
> enough to back-patch.  One can verify that it only changes behavior when
> strerror() returns NULL, an empty string, or something that begins with 
> '?'.
> I can't see resenting the change when that has happened.

Thanks for reviewing the patch.


> Question-mark-damaged messages are not limited to strerror().  A 
> combination
> like lc_messages=ja_JP, encoding=LATIN1, lc_ctype=en_US will produce 
> question
> marks for PG and libc messages even with the 
> bind_textdomain_codeset("libc")
> change.  Is it worth doing anything about that?  That one looks 
> self-inflicted
> in comparison to the lc_messages=ja_JP, encoding=UTF8, lc_ctype=C case.

Year, that might be a bit self-inflicted.  But the problem may not happen 
with lc_messages=ja_JP.UTF-8 and lc_ctype=en_US.UTF-8.  Anyway, I want to 
see this as a separate issue.


Regards
MauMau




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

Предыдущее
От: Ronan Dunklau
Дата:
Сообщение: Triggers on foreign tables
Следующее
От: "MauMau"
Дата:
Сообщение: Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII