Re: More message encoding woes

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).

In response to

Browse pgsql-hackers by date

  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