Re: NLS vs error processing, again
| От | Tom Lane |
|---|---|
| Тема | Re: NLS vs error processing, again |
| Дата | |
| Msg-id | 23732.1144209423@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: Composite Type with Domain (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: NLS vs error processing, again
|
| Список | pgsql-bugs |
Tatsuo Ishii <ishii@sraoss.co.jp> writes:
> As fas as looking into utils/mb/Unicode/euc_cn_to_utf8.map, the
> translation above seems to be correct. BTW, who does the translation
> from EUC-CN to UTF-8? Maybe gettext()?
I'm far from an expert on this, but the gettext documentation indicates
that it tries to translate the .po file contents into whatever encoding
is implied by LC_CTYPE. The fact that the string passed to
utf8_to_iso8859_1 is not identical to the .po file contents indicates
that gettext is doing *something*. I'm a bit worried that this
translation could be out of step with what we will expect the
server_encoding to be --- but there's not any immediate evidence of
that.
Anyway, the real problem seems to be what to do if translation of an
error message to the client_encoding fails. That's clearly a risk even
if gettext has behaved perfectly.
regards, tom lane
В списке pgsql-bugs по дате отправления: