>I don't think it's worth implementing a code path in
> the server like this as it would then become cruft that would be hard
> to ever get rid of.
Do you think the server can de-support the old code path soon?
> I think you can do the same thing, more or less, in the client. Like
> if the driver tries to connect via SSL and gets an error it remembers
> that host/port and connects using negotiation in the future.
Well, I doubt everybody would instantaneously upgrade to the database that supports fast TLS,
so there will be a timeframe when there will be a lot of old databases, and the clients will be new.
In that case, going with "try fast, ignore exception" would degrade performance for old databases.
I see you suggest caching, however, "degrading one of the cases" might be more painful than
"not improving one of the cases".
I would like to refrain from implementing "parallel connect both ways and check which is faster" in
> In practice though, by the time drivers support this it'll probably be
> far enough in the future
I think drivers release more often than the database, and we can get driver support even before the database releases.
I'm from pgjdbc Java driver team, and I think it is unfair to suggest that "driver support is only far enough in the future".
Vladimir