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

From Stephen Frost
Subject Re: Add docs stub for recovery.conf
Date
Msg-id 20201204190023.GV16415@tamriel.snowman.net
Whole thread Raw
In response to Re: Add docs stub for recovery.conf  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Add docs stub for recovery.conf
Re: Add docs stub for recovery.conf
List pgsql-hackers
Greetings,

* Bruce Momjian (bruce@momjian.us) wrote:
> On Wed, Dec  2, 2020 at 08:07:47PM -0500, Isaac Morland wrote:
> > 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.
>
> 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
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.

Obviously, I'd then have to adjust the patch that I proposed for default
roles, or move forward with it as-is, depending on what we end up doing
here.  I dislike what feels like a state of limbo for this right now
though.

Thanks,

Stephen

Attachment

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Improper use about DatumGetInt32
Next
From: Stephen Frost
Date:
Subject: Re: WIP: WAL prefetch (another approach)