From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | MauMau <maumau307(at)gmail(dot)com> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, alvherre(at)2ndquadrant(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [bug fix] multibyte messages are displayed incorrectly on the client |
Date: | 2014-01-11 00:37:38 |
Message-ID: | 20140111003738.GA1710819@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jan 07, 2014 at 10:56:28PM +0900, MauMau wrote:
> From: "Bruce Momjian" <bruce(at)momjian(dot)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
> >>result of GetPlatformEncoding(). If they don't match, call
> >>disable_message_localization().
I like this proposal. Thanks.
> >I think the problem is we don't know the client and server encodings
> >at that time.
>
> 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 encoding of strings gettext() returns. That
> is what GetPlatformEncoding() returns.
Agreed. You would need to poke into the relevant part of the startup packet
much earlier than we do today, but that's tractable. Note that
GetPlatformEncoding() is gone; use GetMessageEncoding().
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2014-01-11 00:38:01 | Re: Standalone synchronous master |
Previous Message | Adrian Klaver | 2014-01-11 00:35:09 | Re: Standalone synchronous master |