Re: [bug fix] multibyte messages are displayed incorrectly on the client

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

In response to

Responses

Browse pgsql-hackers by date

  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