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: