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

From Bruce Momjian
Subject Re: Add docs stub for recovery.conf
Date
Msg-id 20201203011154.GJ20285@momjian.us
Whole thread Raw
In response to Re: Add docs stub for recovery.conf  (Isaac Morland <isaac.morland@gmail.com>)
Responses Re: Add docs stub for recovery.conf
List pgsql-hackers
On Wed, Dec  2, 2020 at 08:07:47PM -0500, Isaac Morland wrote:
> 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.

Yes, that is pretty much the same thing I was suggesting, except that
each rename has its own _original_ URL link, which I think is also
acceptable.  My desire is for these items to all exist in one place, and
an appendix of them seems fine.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee




pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Get memory contexts of an arbitrary backend process
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Huge memory consumption on partitioned table with FKs