Re: [HACKERS] Our feature change policy - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: [HACKERS] Our feature change policy
Date
Msg-id CAKFQuwZZtTPZorNHMdqTu1FuKBN7cKqK2YCWphQ=SeNedQc3Kw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Our feature change policy  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Mon, Mar 20, 2017 at 9:18 AM, Bruce Momjian <bruce@momjian.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.

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] WIP: Faster Expression Processing v4
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] Partition-wise join for join between (declaratively)partitioned tables