Re: Our feature change policy

On Mon, Mar 20, 2017 at 9:18 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> . #3 and #4 would need to be weighted depending on
> whether choosing them would delay progress, e.g. it did delay progress
> on standard-conforming strings, but the delay was determined to be
> reasonable.
>

w.r.t. standard-conforming strings to this day we are in indefinite
deprecation of the backward compatibility mechanics. We simply made the
choice of whether to use the backward compatibility mode explicit when we
changed the GUC default. For features with that possibility adding an "D.
Optionally, when applicable, maintain current behavior during release and
later switch the default behavior to the new mode after N years." Odds are
if we are considering instituting item D we'd be content with discussing
the specifics of the case and not rely on any kind of rule or guideline to
define N. As evidenced defaults and deprecation are orthogonal concerns.

David J.