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

Author

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

Euler Taveira de Oliveira

2006-04-05, 3:30 am

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.

--
Euler Taveira de Oliveira

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Alvaro Herrera

2006-04-05, 9:34 am

Euler Taveira de Oliveira wrote:
> Tom Lane wrote:
>
>
> 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

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Sponsored Links