From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
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:33:08 |
Message-ID: | 20071006153308.GI5618@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Gregory Stark wrote:
> "Alvaro Herrera" <alvherre(at)commandprompt(dot)com> writes:
>
> > Gregory Stark wrote:
> >>
> >> 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 PO files include encoding information, so it's easy for the server
> > to recode them from that to the server (or client) encoding, as
> > appropriate.
>
> So does the _() macro automatically recode it to the current server encoding?
Well, I'm not sure if it's _(), elog() or what, but it does get recoded.
If I have a different client_encoding and get a NOTICE, then both the
server and client get a message in the corresponding encoding.
In fact this is the reason for the most common "PANIC: stack overflow"
in elog.c error stack. When a message needs to be recoded but the
recoding procedure errors out, it wants to report that and this one also
fails, you get infinite recursion and nothing can get reported.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-10-06 15:35:18 | Re: Encoding and i18n |
Previous Message | Tom Lane | 2007-10-06 15:25:34 | Re: Encoding and i18n |