Noah Misch <n...@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.
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.
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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
