Re: Encoding and i18n - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Encoding and i18n
Date
Msg-id 23680.1191684334@sss.pgh.pa.us
Whole thread Raw
In response to Encoding and i18n  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-hackers
Gregory Stark <stark@enterprisedb.com> writes:
> Reading the commit message about the TZ encoding issue I'm curious why this
> isn't a more widespread problem. How does gettext now what encoding we want
> messages in? How do we prevent things like to_char(now(),'month') from
> producing strings in an encoding different from the database's encoding?

The short answer is it's all a house of cards, and if you troll
the archives you will find plenty of bug reports traceable to
misconfiguration in this area.  The recent attempt to enforce
that nl_langinfo(CODESET) matches the database encoding is a first
step towards making this more bulletproof, but we're finding out
that even that is harder than it looks.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Re: Encoding and i18n
Next
From: Alvaro Herrera
Date:
Subject: Re: Encoding and i18n