Re: pgsql: Remove support for SSL compression

Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
> Having tried a number of different ways to fix this I think the least intrusive
> fix is to teach pg_upgrade and dblink about sslcompression, like how've already
> taught it about other options. Building any infrastructure to handle
> deprecated options and extending the dispchar with a classification for
> deprecation for just this one option seems overkill. Deprecating options is
> also not something frequently done, so the cost/benefit for something
> complicated seems off.

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.

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.

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.

regards, tom lane