From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Our feature change policy |
Date: | 2017-03-21 02:58:15 |
Message-ID: | CA+TgmoY+AqsSgTvCJBa6xp1JmErd5NHs+8Js1RLkn3xYjnu74A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Mar 20, 2017 at 10:35 AM, Bruce Momjian <bruce(at)momjian(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro HORIGUCHI | 2017-03-21 03:16:12 | Re: asynchronous execution |
Previous Message | Robert Haas | 2017-03-21 02:54:50 | Re: increasing the default WAL segment size |