On Fri, Dec 18, 2015 at 10:25 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:

> Robert Haas <robertmh...@gmail.com> writes:
> > On Fri, Dec 18, 2015 at 12:10 PM, Andres Freund <and...@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.

David J.

Reply via email to