>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 PG clients (e.g. https://en.wikipedia.org/wiki/Happy_Eyeballs ). Just wondering: do you consider back-porting the feature to all supported DB versions? > 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
