| 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: | Whole Thread | Raw Message | 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 |