> On 9 Mar 2021, at 12:19, Michael Paquier <[email protected]> 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/
v1-0001-Fix-sslcompression-in-postgres_fdw-and-dblink.patch
Description: Binary data
