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

From Bruce Momjian
Subject Re: Add docs stub for recovery.conf
Date
Msg-id 20201216222916.GF4527@momjian.us
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
List pgsql-hackers
On Fri, Dec  4, 2020 at 02:00:23PM -0500, Stephen Frost wrote:
> * Bruce Momjian (bruce@momjian.us) wrote:
> > Yes, that is pretty much the same thing I was suggesting, except that
> > each rename has its own _original_ URL link, which I think is also
> > acceptable.  My desire is for these items to all exist in one place, and
> > an appendix of them seems fine.
> 
> Alright, so, to try and move this forward I'll list out (again) the
> renames that we have in pgweb:
> 
> catalog-pg-replication-slots.html <-> view-pg-replication-slots.html
> pgxlogdump.html <-> pgwaldump.html
> app-pgresetxlog.html <-> app-pgresetwal.html
> app-pgreceivexlog.html <-> app-pgreceivewal.html
> 
> (excluding the 'legal notice' one)
> 
> Bruce, are you saying that we need to take Craig's patch and then add to
> it entries for all of the above, effectively removing the need for the
> web page aliases and redirects?  If that was done, would that be

Yes, I think putting the compatibility section headings in our main
documentation flow will make it too hard to read and cause unnecessary
complexity, but if we have a separate section for them, adding the
section headings seems fine.  This way, we don't have to add a redirect
every time we add a new entry.

> sufficient to get this committed?  Are there other things that people
> can think of off-hand that we should include, I think Craig might have
> mentioned something else earlier on..?  I don't think we should require
> that someone troll through everything that ever existed, just to be
> clear, as we can always add to this later if other things come up.  If
> that's the expectation though, then someone needs to say so, in which
> case I'll assume it's status quo unless/until someone steps up to do
> that.

Agreed.  I just wanted something that could scale going forward, and be
easily identified as compatibility, so maybe one day we can remove them.
However, if they are in a separate section, we might never do that.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee




pgsql-hackers by date:

Previous
From: Alastair Turner
Date:
Subject: Re: Proposed patch for key managment
Next
From: Tom Lane
Date:
Subject: Re: \gsetenv