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

From MauMau
Subject Re: [bug fix] strerror() returns ??? in a UTF-8/C database withLC_MESSAGES=non-ASCII
Date
Msg-id 2EA0B1A05B764781AD94C7124ECDEE33@maumau
Whole thread Raw
In response to Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII  (Noah Misch <noah@leadboat.com>)
List 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 by date:

Previous
From: Ronan Dunklau
Date:
Subject: Triggers on foreign tables
Next
From: "MauMau"
Date:
Subject: Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII