Re: Add docs stub for recovery.conf
Isaac Morland <isaac.morland@gmail.com>
From: Isaac Morland <isaac.morland@gmail.com>
To: "David G. Johnston" <david.g.johnston@gmail.com>
Cc: Bruce Momjian <bruce@momjian.us>, Stephen Frost <sfrost@snowman.net>, Craig Ringer <craig.ringer@enterprisedb.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-12-03T01:07:47Z
Lists: pgsql-hackers
On Wed, 2 Dec 2020 at 19:33, David G. Johnston <david.g.johnston@gmail.com> wrote: > On Wed, Dec 2, 2020 at 5:26 PM Bruce Momjian <bruce@momjian.us> wrote: > >> I think the ideal solution is to create a section for all the rename >> cases and do all the redirects to that page. The page would list the >> old and new name for each item, and would link to the section for each >> new item. >> >> > Nothing prevents us from doing that for simple renames. For me, this > situation is not a simple rename and the proposed solution is appropriate > for what it is - changing the implementation details of an existing > feature. We can do both - though the simple rename page doesn't seem > particularly appealing at first glance. > I for one do not like following a bookmark or link and then being redirected to a generic page that doesn't relate to the specific link I was following. What is being proposed here is not as bad as the usual, where all the old links simply turn into redirects to the homepage, but it's still disorienting. I would much rather each removed page be moved to an appendix (without renaming) and edited to briefly explain what happened to the page and provide links to the appropriate up-to-date page or pages.
Commits
-
Add a docs section for obsoleted and renamed functions and settings
- 3b0c647bbfc5 14.0 landed
- 89e383b30a94 13.3 landed
- 448e86c3345b 12.7 landed
- 625f5aae7e42 11.12 landed
- 58960fca4ef1 10.17 landed