Re: Add docs stub for recovery.conf

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

On Thu, 14 Jan 2021 at 03:44, Stephen Frost <sfrost(at)snowman(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2021-01-18 04:08:07 Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit
Previous Message Etsuro Fujita 2021-01-18 04:06:23 Re: Asynchronous Append on postgres_fdw nodes.