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
|
Список | 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 по дате отправления: