Re: BUG #7664: Program using libpq and ecpglib can not output native language

The following bug has been logged on the website:

Bug reference: 7664
Logged by: Chen Huajun
Email address: chenhj(at)cn(dot)fujitsu(dot)com
PostgreSQL version: 9.1.6
Operating system: Linux
Description:

The error messages output by libpq or ecpglib is always be english. But my
expect is my native language.

Step:
1)compile my program which linked to libpq or ecpglib.
2)set my locale to native language.
set LANG=ja_JP.UTF-8
set LC_ALL=ja_JP.UTF-8
3)run my program and let it raise an error.

I knows reason. The default locale of a program is "C" in Linux,regardless
the Environment Variables.
if add the following line in my program,everything is OK.

setlocale(LC_ALL, "");

But I found no document tell users should do so.And I think it's not a easy
way.Can libpq and ecpglib do it for users?

*）Windows is OK.Solaris may has the same problem.

chenhj(at)cn(dot)fujitsu(dot)com writes:
> I knows reason. The default locale of a program is "C" in Linux,regardless
> the Environment Variables.
> if add the following line in my program,everything is OK.

> setlocale(LC_ALL, "");

> But I found no document tell users should do so.And I think it's not a easy
> way.Can libpq and ecpglib do it for users?

No, it would most certainly be inappropriate for a library to do that.
setlocale could completely break a program that wasn't expecting it.
The effects would be global across the whole process, not confined to
the library.

regards, tom lane

Hi,tom lane

> No, it would most certainly be inappropriate for a library to do that.
> setlocale could completely break a program that wasn't expecting it.
> The effects would be global across the whole process, not confined to
> the library.

First,does you agree with the need of native language support without writing
"setlocale(LC_ALL, "")"in user's program is rational？
If the answer is yes, let see if there is a mothod to solve it.
Simply write "setlocale(LC_ALL, "")" in libpq and ecpglib may cause other
problems as you said. But how about only call setlocale() before call dgettext(),
and soon restore to the original value after called.

*)Excuse me for my English.

for example:
libpq_gettext(const char *msgid):
=====================================================
return dgettext(PG_TEXTDOMAIN("libpq"), msgid);

==>
char *result;
if(strcmp(setlocale(LC_MESSAGES,NULL),"C")==0)
{
setlocale(LC_MESSAGES, "");
result = dgettext(PG_TEXTDOMAIN("libpq"), msgid);
setlocale(LC_MESSAGES, "C");
}else
{
result = dgettext(PG_TEXTDOMAIN("libpq"), msgid);
}
return result;
=====================================================

(2012/11/16 13:22), Tom Lane wrote:
> chenhj(at)cn(dot)fujitsu(dot)com writes:
>> I knows reason. The default locale of a program is "C" in Linux,regardless
>> the Environment Variables.
>> if add the following line in my program,everything is OK.
>
>> setlocale(LC_ALL, "");
>
>> But I found no document tell users should do so.And I think it's not a easy
>> way.Can libpq and ecpglib do it for users?
>
> No, it would most certainly be inappropriate for a library to do that.
> setlocale could completely break a program that wasn't expecting it.
> The effects would be global across the whole process, not confined to
> the library.
>
> regards, tom lane
>
>

--
Best Regards,
chen hujuan

Chen Huajun <chenhj(at)cn(dot)fujitsu(dot)com> writes:
> First,does you agree with the need of native language support without writin
> "setlocale(LC_ALL, "")"in user's program is rational?

No, not particularly. The C language standard is quite clear about
that. Nor does it seem like a particularly great idea from a user's
standpoint for different sub-parts of a program to be operating in
different locales. Even if I agreed with the concept, your idea of
switching locale constantly is likely to be horrid from a performance
standpoint.

regards, tom lane

> No, not particularly. The C language standard is quite clear about
> that. Nor does it seem like a particularly great idea from a user's
> standpoint for different sub-parts of a program to be operating in
> different locales. Even if I agreed with the concept, your idea of
> switching locale constantly is likely to be horrid from a performance
> standpoint.

I just don't known way the default locale is "C" but not the value
Set by Environment Variables in Linux. Maybe this is The C language standard.
And may be this is a general knowledge known by most of people except for
a few (just like me ).
If someone does not know that,it's not too easy to solve it by him self.
Whether it's better to do something
to make using native language of libpq more easy?
Even if write something in document.

By the way, from a performance standpoint normally native language only needed for
error message outputing where I think performance is not so important.

Regards
chen huajun