Re: Encoding and i18n

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

In response to

Responses

Browse pgsql-hackers by date

  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