From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Subject: | Re: More message encoding woes |
Date: | 2009-04-02 19:48:38 |
Message-ID: | 200904022248.39545.peter_e@gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Monday 30 March 2009 15:52:37 Heikki Linnakangas wrote:
> What is happening is that gettext() returns the message in the encoding
> determined by LC_CTYPE, while we expect it to return it in the database
> encoding. Starting with PG 8.3 we enforce that the encoding specified in
> LC_CTYPE matches the database encoding, but not for the C locale.
>
> In CVS HEAD, we call bind_textdomain_codeset() in SetDatabaseEncoding()
> which fixes that, but we only do it on Windows. In earlier versions we
> called it on all platforms, but only for UTF-8. It seems that we should
> call bind_textdomain_codeset on all platforms and all encodings.
> However, there seems to be a reason why we only do it for Windows on CVS
> HEAD: we need a mapping from our encoding ID to the OS codeset name, and
> the OS codeset names vary.
>
> How can we make this more robust?
Another approach might be to create a new configuration parameter that
basically tells what encoding to call bind_textdomain_codeset() with, say
server_encoding_for_gettext. If that is not set, you just use server_encoding
as is and hope that gettext() takes it (which it would in most cases, I
guess).
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-04-02 19:49:59 | Re: [COMMITTERS] pgsql: If we expect a hash join to be performed in multiple batches, |
Previous Message | Jeff Davis | 2009-04-02 19:40:16 | Re: [HACKERS] Mentors needed urgently for SoC & PostgreSQL Student Internships |