Re: NLS vs error processing, again (was Re: Composite Type

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: NLS vs error processing, again (was Re: Composite Type
Дата
Msg-id 20060405121320.GA6720@surnet.cl
обсуждение исходный текст
Ответ на Re: NLS vs error processing, again (was Re: Composite Type  (Euler Taveira de Oliveira <euler@timbira.com>)
Список pgsql-bugs
Euler Taveira de Oliveira wrote:
> Tom Lane wrote:
>
> >It seems to me that there basically is no graceful solution to this sort
> >of mismatch.  It might be possible to kluge things so that we disable
> >NLS once we've recursed too many times in error processing, but that's
> >surely pretty ugly.  What would be a lot more user-friendly would be to
> >refuse the attempt to set client_encoding to something that can't handle
> >our error message encoding, but I don't know what a reasonable set of
> >restrictions would be.
>
> Maybe it's the time to convert all PO files to UTF-8. I'm in process to
> convert pt_BR ones.

I don't understand what do you think would be gained by doing that.  If
the message has chinese chars, a recode from UTF8 to Latin1 is as bad as
GB1232 to Latin1.

What needs to be done for this to work is to refuse trying to recode, as
Tom proposes above.  We would need to determine what recodes are "safe";
for example, (I think) valid encodings to Latin1 (iso 8859-1) are from
Latin9 (iso 8859-15 ?), Unicode and Win1252 and ASCII.  If the server
encoding or the encoding of the message files is a chinese encoding,
setting client_encoding to latin1 would raise an error.

The problem, I think, would be in determining what recodings are sane.

--
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

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

Предыдущее
От: "Qingqing Zhou"
Дата:
Сообщение: Re: contrib/intarray/_int_gist.c
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: NLS vs error processing, again