Re: Encoding and i18n

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: Encoding and i18n
Дата
Msg-id 20071006153308.GI5618@alvh.no-ip.org
обсуждение исходный текст
Ответ на Re: Encoding and i18n  (Gregory Stark <stark@enterprisedb.com>)
Ответы Re: Encoding and i18n  (Gregory Stark <stark@enterprisedb.com>)
Список pgsql-hackers
Gregory Stark wrote:
> "Alvaro Herrera" <alvherre@commandprompt.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Encoding and i18n
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Encoding and i18n