On Sat, Dec 17, 2016 at 5:42 AM, Bruce Momjian <bruce@momjian.us> wrote:
On Fri, Dec 16, 2016 at 08:52:25PM -0500, Robert Haas wrote: > On Fri, Dec 16, 2016 at 8:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > I'm still not seeing any value in putting this sort of info into > > a documentation section that's distinct from the release notes. > > We've used links to wiki pages in the past when the information > > seemed to be in flux, and that's reasonable. But what's the point > > of just linking to somewhere else in the same document? > > If the explanation is just a few sentences long, I see no reason not > to include it in the release notes. But if it's comparable in length > to a moderately-long chapter then why would we not make it its own > chapter? I think your argument boils down to "people probably don't > need very much detail about this". But I think that's the wrong line > of thinking. In my view, we ought to ship just about as much quality > documentation as people are willing to write. Saying that we're going > to reject good-quality documentation because we don't want to have too > much of it is like saying we want to reject good-quality features > because we don't want to have too many of them, or good-quality > regression tests because we don't want to have too much code coverage,
[ I stopped reading after this. ]
The point is that the documentation about the recovery.conf changes in Postgres are only interesting to people migrating to Postgres 10, i.e. this is not quality documentation for someone going from Postgres 10 to Postgres 11.
They will also be interesting to people going from 9.4 to 11, or from 9.3 to 12. Or from 9.5 to 13.
They only become uninteresting when we stop supporting 9.6 which is the last version that didn't have that functionality.