Re: Add docs stub for recovery.conf

From: Isaac Morland <isaac(dot)morland(at)gmail(dot)com>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add docs stub for recovery.conf
Date: 2020-12-03 01:07:47
Message-ID: CAMsGm5f-GfdW9cDr+Dy5ex1S4+6NSCDOb8mVLXvtUVKP9VF6rg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 2 Dec 2020 at 19:33, David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
wrote:

> On Wed, Dec 2, 2020 at 5:26 PM Bruce Momjian <bruce(at)momjian(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2020-12-03 01:10:06 Re: Get memory contexts of an arbitrary backend process
Previous Message Julien Rouhaud 2020-12-03 01:00:51 Re: pg_stat_statements oddity with track = all