On Tue, Mar 09, 2021 at 10:58:21AM -0500, Tom Lane wrote: > I'm fairly distressed by this patch series, and this proposed change in > particular, because it seems to be going in very much the wrong direction. > The objective ought to be simplification, but you're doing exactly the > opposite.
Yeah. I'd rather simplify things more. > Also, the changes in postgres_fdw.out remind me way too much of this > problem my successors at Red Hat are fighting: > > https://bugzilla.redhat.com/show_bug.cgi?id=1915179 > > The context there is that they are now shipping concurrently-installable > packages for a couple of different PG versions, but they only install > the latest available version of libpq.so into /usr/lib, figuring that > the back-rev versions can rely on that one. Maybe that's a foolish idea > on their part (but I have a vague idea that Debian does something > similar?). Any such setup is going to have pain whenever we change > the externally-visible behavior of libpq. Err. That's indeed a weird choice as I would have though that any past version of postgres_fdw.so or dblink.so would link to their respective libpq, but that makes LD_LIBRARY_PATH a no-brainer. > I'm inclined to think that we should leave this parameter completely > alone, and at most choose to ignore its value internally to libpq. > But really, why is there urgency to do anything at all with it? > It's not our business whether OpenSSL chooses to ignore it. > > In short, I think I'm a vote for reverting to the v13 behavior. The libpq part is a good point, as it could be annoying for people to get a changing behavior once the libpq version changes for anything using the older major version binaries once the newer libpq is out. I am still in favor of keeping the simplifications in the backend though as it simplifies some catalogs and PgBackendSSLStatus, and we know that SSL compression does not really matter these days. -- Michael
signature.asc
Description: PGP signature
