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

From MauMau
Subject Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII
Date
Msg-id 88EE8A950D4743B1931E69DB710CCA1D@maumau
Whole thread Raw
In response to Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII
Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII
List pgsql-hackers
From: "Tom Lane" <tgl@sss.pgh.pa.us>
> Noah Misch <noah@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.  I would be fine
> with handling that as a 9.4-only patch (preferably with the usual review
> process).

> Still, libc is certainly the source of the vast majority of
> potentially-translated messages that we might be passing through to users,
> so fixing it would be a step forward.


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.


Regards
MauMau




pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: lcr v5 - introduction of InvalidCommandId
Next
From: "Daniel Vérité"
Date:
Subject: Re: file_fdw target file ownership