On Fri, 20 Jan 2023 at 01:41, Vladimir Sitnikov <sitnikov.vladi...@gmail.com> wrote: > > Do you think the server can de-support the old code path soon?
I don't have any intention to de-support anything. I really only picture it being an option in environments where the client and server are all part of a stack controlled by a single group. User tools and general purpose tools are better served by our current more flexible setup. > Just wondering: do you consider back-porting the feature to all supported DB > versions? I can't see that, no. > > 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". Interesting. I didn't realize this would be so attractive to regular driver authors. I did think of the Happy Eyeballs technique too but I agree I wouldn't want to go that way either :) I guess the server doesn't really have to do anything specific to do what you want. You could just hard code that servers newer than a specific version would have this support. Or it could be done with a "protocol option" -- which wouldn't actually change any behaviour but would be rejected if the server doesn't support "fast ssl" giving you the feedback you expect without having much extra legacy complexity. I guess a lot depends on the way the driver works and the way the application is structured. Applications that make a single connection or don't have shared state across connections wouldn't think this way. And interfaces like libpq would normally just leave it up to the application to make choices like this. But I guess JVM based applications are more likely to have long-lived systems that make many connections and also more likely to make it the driver's responsibility to manage such things. -- greg
