Re: [HACKERS] Our feature change policy

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] Our feature change policy
Дата
Msg-id CA+TgmoY+AqsSgTvCJBa6xp1JmErd5NHs+8Js1RLkn3xYjnu74A@mail.gmail.com
обсуждение исходный текст
Ответ на [HACKERS] Our feature change policy  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
On Mon, Mar 20, 2017 at 10:35 AM, Bruce Momjian <bruce@momjian.us> wrote:
> We keep re-litigating changes, either with pg_xlog, binaries, or
> pg_stat_activity, and at some point we need to settle on a
> policy.  The usual "change" options are:
>
> 1.  make the change now and mention it in the release notes
> 2.  #1, but also provide backward compatibility for 5+ years
> 3.  mark the feature as deprecated and remove/change it in 5+ years
> 4.  #3, but issue a warning for deprecated usage
>
> What causes us to choose different outcomes?

Well, sometimes backward compatibility is more possible than at other
times.  With standard_confirming_strings, we made it a GUC, but that
doesn't work with renaming a column in pg_stat_activity.  Also,
there's a big difference in my mind between changes that affect DBAs
and changes that affect user queries.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] increasing the default WAL segment size
Следующее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: [HACKERS] asynchronous execution