Re: Add docs stub for recovery.conf - Mailing list pgsql-hackers

From Isaac Morland
Subject Re: Add docs stub for recovery.conf
Date
Msg-id CAMsGm5f-GfdW9cDr+Dy5ex1S4+6NSCDOb8mVLXvtUVKP9VF6rg@mail.gmail.com
Whole thread Raw
In response to Re: Add docs stub for recovery.conf  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re: Add docs stub for recovery.conf
List 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.

pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: pg_stat_statements oddity with track = all
Next
From: Fujii Masao
Date:
Subject: Re: Get memory contexts of an arbitrary backend process