On Tue, Sep 10, 2013 at 05:42:06AM +0900, MauMau wrote: > From: "Tom Lane" <t...@sss.pgh.pa.us> >> Noah Misch <n...@leadboat.com> writes: >>> ... I think >>> MauMau's original bind_textdomain_codeset() proposal was on the right >>> track. >> >> It might well be. My objection was to the proposal for back-patching it >> when we have little idea of the possible side-effects.
Agreed. > We are using 9.1/9.2 and 9.2 is probably dominant, so I would be relieved > with either of the following choices: > > 1. Take the approach that doesn't use bind_textdomain_codeset("libc") > (i.e. the second version of errno_str.patch) for 9.4 and older releases. > > 2. Use bind_textdomain_codeset("libc") (i.e. take strerror_codeset.patch) > for 9.4, and take the non-bind_textdomain_codeset approach for older > releases. 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. Note that you can work around the problem today by linking PostgreSQL with a better iconv() implementation. 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. -- Noah Misch EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers