Re: [HACKERS] Our feature change policy
От | David G. Johnston |
---|---|
Тема | Re: [HACKERS] Our feature change policy |
Дата | |
Msg-id | CAKFQuwZZtTPZorNHMdqTu1FuKBN7cKqK2YCWphQ=SeNedQc3Kw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Our feature change policy (Bruce Momjian <bruce@momjian.us>) |
Список | pgsql-hackers |
. #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 по дате отправления: