On Fri, Jan 10, 2014 at 08:03:00PM -0500, Tom Lane wrote:
> Noah Misch <noah@leadboat.com> writes:
> >> 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.
> > ...
> > Agreed. You would need to poke into the relevant part of the startup packet
> > much earlier than we do today, but that's tractable.
>
> There's still the problem of what to do before we have a complete startup
> packet, or if the packet is defective enough to not contain a recognizable
> client encoding.
MauMau proposed using untranslated messages until we're past that point. I
like that answer fine, because routine mistakes from ordinary users will not
elicit the errors in question. The most interesting message in that group
might be 'invalid value for parameter "client_encoding"', and I think the
presence of the term "client_encoding" will be a sufficient clue regardless of
how we translate and encode the surrounding words.
> Perhaps more to the point, what it sounds like this is doing is creating
> a third behavioral state, in between what prevails when we're first
> reading the packet and what prevails after we've finally adopted the
> requested client encoding. I'm less than convinced that's a good thing.
>
> I'm also rather unexcited by the idea of introducing redundant and/or
> ad-hoc code to parse the startup packet. That sounds like a recipe for
> bugs, some of which might even rise to security issues, considering it
> would happen before client authentication.
Valid worries.
> I think if we're going to do anything like this at all, it'd be best
> just to disable localization from postmaster fork up till we've gotten
> a client encoding out of the packet in the normal course of events.
That was MauMau's original proposal. I opined upthread that it would be
better to change nothing than to do that.
nm
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com