On Tue, Jan 07, 2014 at 10:56:28PM +0900, MauMau wrote: > 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 > >>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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
