Re: pgsql: Remove support for SSL compression

> On 9 Mar 2021, at 12:19, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Tue, Mar 09, 2021 at 12:26:15PM +0900, Michael Paquier wrote:
>> It looks like it is not that much a good idea to define it as a debug
>> option after all. So I guess that the attached would fix the failure,
>> where FDW servers can still pass down the parameter at will for
>> backward-compatibility, and where libpq keeps ignoring its value. Any
>> thoughts?
>
> So, I have been thinking more about this one, and applied the previous
> patch to bring back crake to green. There are a couple of options
> that could be considered to make the option non-visible, but nothing
> looks really appealing to me:
> - Tweak the regression tests on the back-branches to bypass the
> failure, but this won't change the potential impact of anybody using
> sslcompression in a FDW server, or even dblink.
> - Create specific exceptions in postgres_fdw and perhaps dblink.
> - Extend libpq with a special status to mark a parameter as
> to-be-removed, but that feels like a mix of a normal option and a
> debug option.
> - Make pg_upgrade complain if such a server is detected (?), bringing
> in the ring the first point of this list.

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.

The attached is a version of the simple fix.

--
Daniel Gustafsson https://vmware.com/