"MauMau" 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, call
>> disa
From: "Robert Haas"
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 (pgsql-hackers@postgresql.o
From: "Robert Haas"
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 (pgsql-hackers@postgresql.o
On Tue, Jan 7, 2014 at 8:56 AM, MauMau 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 encoding - the e
From: "Bruce Momjian"
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
result of GetPlatfo
From: "Noah Misch"
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, perhaps explaining in
From: "Noah Misch"
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 expect such an ende
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 cl
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 appro
