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

From: "MauMau" <maumau307(at)gmail(dot)com>
To: "Noah Misch" <noah(at)leadboat(dot)com>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Peter Eisentraut" <peter_e(at)gmx(dot)net>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [bug fix] strerror() returns ??? in a UTF-8/C database withLC_MESSAGES=non-ASCII
Date: 2013-09-10 12:38:17
Message-ID: 2EA0B1A05B764781AD94C7124ECDEE33@maumau
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

From: "Noah Misch" <noah(at)leadboat(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2013-09-10 12:45:14 Re: strange IS NULL behaviour
Previous Message Ronan Dunklau 2013-09-10 12:08:20 Triggers on foreign tables