On Fri, Dec 18, 2015 at 10:25 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes: > On Fri, Dec 18, 2015 at 12:10 PM, Andres Freund <andres@anarazel.de> wrote: >> I'm saying that 10 year deprecation periods don't make sense. Either we >> decide to remove the compat switch because we dislike it for $reasons, >> in which case it should be removed sooner. Or we decide to keep the >> switch indefinitely.
> Forever is an awfully long time. I think that it's OK to remove > backward-compatibility features at some point even if they're not > really harming anything. I think the time before we do that should be > long, but I don't think it needs to be forever.
Maybe I shouldn't put words in Andres' mouth, but I don't think that by "indefinitely" he meant "forever". I read that more as "until some positive reason to remove it arrives". I could imagine that at some point we decide to do a wholesale cleanup of backwards-compatibility GUCs, and then we'd zap this one along with others.
Hand-waving from me but I see a "positive reason" being that someone wants to write and commit a patch that does not play nicely with the old behavior. That patch can then do away with giving the user an option as long as the GUC itself was introduced in a now unsupported release.
I do not have a feel for how much grief having these GUCs in the code causes but if the concern is for the end-user then simply removing them from (or tucking them into a dark corner of) the documentation seems like it would be the most useful means of "removing" while still be friendly to users that just haven't wanted to update their application code to the new way of doing things.