MauMau maumau...@gmail.com writes:
Then, as a happy medium, how about disabling message localization only if
the client encoding differs from the server one? That is, compare the
client_encoding value in the startup packet with the result of
GetPlatformEncoding(). If they don't match,
On Tue, Jan 7, 2014 at 8:56 AM, MauMau maumau...@gmail.com wrote:
I suppose we know (or at least believe) those encodings during backend
startup:
* client encoding - the client_encoding parameter passed in the startup
packet, or if that's not present, client_encoding GUC value.
* server
From: Robert Haas robertmh...@gmail.com
Suppose the startup packet itself is malformed. How will you report the
error?
I think we have no choice but to report the error in English, because we
don't know what the client wants.
Regards
MauMau
--
Sent via pgsql-hackers mailing list
From: Robert Haas robertmh...@gmail.com
Suppose the startup packet itself is malformed. How will you report the
error?
I think we have no choice but to report the error in English, because we
don't know what the client wants.
Regards
MauMau
--
Sent via pgsql-hackers mailing list
From: Bruce Momjian br...@momjian.us
On Sun, Jan 5, 2014 at 04:40:17PM +0900, MauMau wrote:
Then, as a happy medium, how about disabling message localization
only if the client encoding differs from the server one? That is,
compare the client_encoding value in the startup packet with the
From: Noah Misch n...@leadboat.com
I agree that English consistently beats mojibake. I question whether that
makes up for the loss of translation when encodings do happen to match,
particularly for non-technical errors like a mistyped password. The
everything-UTF8 scenario appears often,
From: Noah Misch n...@leadboat.com
Better to attack that directly. Arrange to apply any client_encoding
named in
the startup packet earlier, before authentication. This relates to the
TODO
item Let the client indicate character encoding of database names, user
names, and passwords. (I
On Fri, Dec 13, 2013 at 10:41:17PM +0900, MauMau wrote:
[Cause]
While the session is being established, the server cannot use the
client encoding for message conversion yet, because it cannot access
system catalogs to retrieve conversion functions. So, the server
sends messages to the client
Hello,
The attached patch fixes incorrect message output on the client side. I
guess this problem can happen with any major release. Could you review
this?
[Problem]
When the client's locale differs from the server's message locale, the
messages generated on the server are converted
