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

From Noah Misch
Subject Re: Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII
Date
Msg-id 20130910015444.GA219994@tornado.leadboat.com
Whole thread Raw
In response to Re: Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII
List pgsql-hackers
On Mon, Sep 09, 2013 at 05:49:38PM -0400, Peter Eisentraut wrote:
> On 9/9/13 2:57 PM, Noah Misch wrote:
> > Actually, GNU libiconv's iconv() decides that //translit is unimplementable
> > for some of the characters in that file, and it fails the conversion.  GNU
> > libc's iconv(), on the other hand, emits the question marks.
> 
> That can't be right, because the examples I produced earlier (which
> produced question marks) were produced on OS X with GNU libiconv.

Hmm.  I get the "good" behavior (decline to transliterate Japanese) with these
"iconv --version" strings:

iconv (GNU libiconv 1.11) [/usr/bin/iconv on Mac OS X 10.7]
iconv (GNU libiconv 1.14) [recently-updated fink]
iconv (GNU libiconv 1.14) [recently-updated Cygwin]

I also saw that on OpenBSD and NetBSD, though I'm not in an immediate position
to check the libiconv versions there.  I get the "bad" behavior (question
marks) on these:

iconv (GNU libc) 2.12 [Centos 6.4]
iconv (GNU libc) 2.3.4 [CentOS 4.4]
iconv (Ubuntu EGLIBC 2.15-0ubuntu10.4) 2.15 [Ubuntu 12.04]
iconv (GNU libc) 2.5 [Ubuntu 7.04]

That sure looked like GNU libc vs. GNU libiconv, but I guess I'm missing some
other factor.  What is your GNU libiconv version that emits question marks?

Thanks,
nm

-- 
Noah Misch
EnterpriseDB                                 http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers
Next
From: Peter Eisentraut
Date:
Subject: Re: Re: Privileges for INFORMATION_SCHEMA.SCHEMATA (was Re: [DOCS] Small clarification in "34.41. schemata")