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

From Craig Ringer
Subject Re: Add docs stub for recovery.conf
Date
Msg-id CAGRY4nyHrs8F8H-cfqcmwvidS5rXUEsUeQEVWx9UL3rgD1fONA@mail.gmail.com
Whole thread Raw
In response to Re: Add docs stub for recovery.conf  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Add docs stub for recovery.conf  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers

On Thu, 14 Jan 2021 at 03:44, Stephen Frost <sfrost@snowman.net> wrote:

Alright, how does this look?  The new entries are all under the
'obsolete' section to keep it out of the main line, but should work to
'fix' the links that currently 404 and provide a bit of a 'softer'
landing for the other cases that currently just forcibly redirect using
the website doc alias capability.

Thanks for expanding the change to other high profile obsoleted or renamed features and tools.

One minor point. I'm not sure this is quite the best way to spell the index entries:

+   <indexterm>
+     <primary>obsolete</primary>
+     <secondary>pg_receivexlog</secondary>
+   </indexterm>

as it will produce an index term "obsolete" with a list of various components under it. While that concentrates them nicely, it means people won't actually find them if they're using the index alphabetically.

I'd slightly prefer


+   <indexterm>
+     <primary>pg_receivexlog</primary>
+     <seealso>pg_receivewal</secondary>
+   </indexterm>

even though that bulks the index up a little, because then people are a bit more likely to find it.

Your extended and revised patch retains the above style for

+   <indexterm>
+     <primary>trigger_file</primary>
+     <seealso>promote_trigger_file</seealso>
+    </indexterm>
...
+    <indexterm>
+     <primary>standby_mode</primary>
+     <seealso>standby.signal</seealso>
+    </indexterm>

so if you intend to change it, that entry needs changing too.


I ended up not actually doing this for the catalog -> view change of
pg_replication_slots simply because I don't really think folks will
misunderstand or be confused by that redirect since it's still the same
relation.  If others disagree though, we could certainly change that
too.

I agree with you.


pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: Asynchronous Append on postgres_fdw nodes.
Next
From: Fujii Masao
Date:
Subject: Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit