Re: Add docs stub for recovery.conf

Поиск
Список
Период
Сортировка
От Isaac Morland
Тема Re: Add docs stub for recovery.conf
Дата
Msg-id CAMsGm5f-GfdW9cDr+Dy5ex1S4+6NSCDOb8mVLXvtUVKP9VF6rg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Add docs stub for recovery.conf  ("David G. Johnston" <david.g.johnston@gmail.com>)
Ответы Re: Add docs stub for recovery.conf  (Bruce Momjian <bruce@momjian.us>)
Список 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 по дате отправления:

Предыдущее
От: Julien Rouhaud
Дата:
Сообщение: Re: pg_stat_statements oddity with track = all
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: Get memory contexts of an arbitrary backend process