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.
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 |