| 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: | Whole Thread | Raw Message | 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 |