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

From Tom Lane
Subject Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII
Date
Msg-id 18204.1378736710@sss.pgh.pa.us
Whole thread Raw
In response to Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> My suggestion in this matter is to disable gettext processing when
> LC_CTYPE is set to C.  We could log a warning when LC_MESSAGES is set to
> something and LC_CTYPE is set to C.  Or just do the warning and keep
> logging.  Something like that.

Meh.  Seems that would only prevent one specific instance of the general
problem that strerror can fail to translate its result.  Other locale
combinations might create the same kind of failure.

More generally, though, is strerror actually using gettext at all, or
some homegrown implementation?  As I said upthread, I would expect that
gettext("foo") returns the given ASCII string "foo" if it fails to create
a translated version.  This is evidently not what's happening in strerror.

It's way past time to look into the glibc sources and see what it's
actually doing...
        regards, tom lane



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: ENABLE/DISABLE CONSTRAINT NAME
Next
From: Peter Eisentraut
Date:
Subject: Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII