On Mon, Mar 20, 2017 at 11:57:13AM -0400, Stephen Frost wrote: > Tom, > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > Stephen Frost <sfr...@snowman.net> writes: > > > * Bruce Momjian (br...@momjian.us) wrote: > > >> 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 ... > > Well, to what extent are we "holding up progress" in this particular > > case? There is no other development work that's stalled by not renaming > > these binaries. I think there should be some explicit accounting for > > the impact of delay if we're going to try to formalize these decisions > > better. > > The rename of the binaries is case #2 above, at least as I was thinking > of it. I don't believe we are holding up progress in that case.
Agreed. > I was imagining the changes to pg_stat_activity as possibly falling > under #3/change, meaning that we'd wait for 5 years before actually > renaming those columns, which is part of why I was objecting to that > idea. Yes, that is a good point. Removing contrib/tsearch2 or contrib/xml2 is really not holding up progress on anything, but not delaying the addition of wait event reporting to pg_stat_activity is certainly holding up progress. #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. > If we're able to make the change and provide backwards compatibility > then I think the main question is if it's worth it to do so and, if so, > when are we going to remove that backwards compatibility. If we don't > expect to ever be able to remove it, then that's an issue. Agreed. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers