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

From: Chen Huajun <chenhj(at)cn(dot)fujitsu(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #7664: Program using libpq and ecpglib can not output native language
Date: 2012-11-17 04:09:15
Message-ID: 50A70DEB.1050707@cn.fujitsu.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

> 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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Euler Taveira 2012-11-17 17:55:52 Re: BUG #7667: Segmentation fault
Previous Message Euler Taveira 2012-11-16 20:30:57 Re: BUG #7667: Segmentation fault