Magnus Hagander <mha@sollentuna.net> writes:
>> Actually, it shouldn't matter whether the server is 6.6-without-SSL
>> or pre-6.6. At least in the way I envisioned it, they'd act the same.
> The 6.6-without-SSL still knows about the NEGOTIATE_SSL_CODE packet that is
> sent, and can respond "No, I can't do SSL". The pre-6.6 does not know about
> the existance of this packet, and will thus respond with "Unsupported
> Frontend Protocol" (since it's a normal StartupPacket with the version
> number set to something very large (like the cancel request was
> implemented)).
OK, the point being that then the client can either break the connection
(if it doesn't want to do an insecure connection) or send a
StartupPacket to continue with an insecure connection. I agree this
will be a little quicker than tearing down the connection and starting
a new one, which is what must happen in the case of an old server.
But you could save some code on both sides if you just made the
teardown/new connection behavior the only path for falling back to
non-SSL. I'm not sure that SSL-enabled-client-talking-to-6.6-but-
not-SSL-enabled-server will be a sufficiently common scenario to
justify a lot of extra code to make it a tad faster. You'd expect
that most installations will have SSL at the server if they have
it anywhere.
If it's only a small amount of extra code then it doesn't matter,
of course. I'm just dubious that it's worth taking extra care
for that case when you are going to have the other case anyway.
regards, tom lane