Re: pgsql: Remove support for SSL compression

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