Re: [bug fix] multibyte messages are displayed incorrectly on the client - Mailing list pgsql-hackers

From Noah Misch
Subject Re: [bug fix] multibyte messages are displayed incorrectly on the client
Date
Msg-id 20140111003738.GA1710819@tornado.leadboat.com
Whole thread Raw
In response to Re: [bug fix] multibyte messages are displayed incorrectly on the client  ("MauMau" <maumau307@gmail.com>)
Responses Re: Re: [bug fix] multibyte messages are displayed incorrectly on the client  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Jan 07, 2014 at 10:56:28PM +0900, MauMau wrote:
> From: "Bruce Momjian" <bruce@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
> >>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



pgsql-hackers by date:

Previous
From: Adrian Klaver
Date:
Subject: Re: Standalone synchronous master
Next
From: Stephen Frost
Date:
Subject: Re: Standalone synchronous master