Daniel Gustafsson <[email protected]> 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
