From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
Cc: | PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Encoding and i18n |
Date: | 2007-10-06 15:25:34 |
Message-ID: | 23680.1191684334@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Gregory Stark <stark(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2007-10-06 15:33:08 | Re: Encoding and i18n |
Previous Message | Gregory Stark | 2007-10-06 15:19:43 | Re: Encoding and i18n |