> On Mar 24, 2022, at 4:12 PM, Thomas Munro <thomas.mu...@gmail.com> wrote: > > On Fri, Mar 25, 2022 at 1:43 AM David Christensen > <david.christen...@crunchydata.com> wrote: >>>> On Mar 24, 2022, at 6:43 AM, Thomas Munro <thomas.mu...@gmail.com> wrote: >>> On Fri, Mar 25, 2022 at 12:26 AM Thomas Munro <thomas.mu...@gmail.com> >>> wrote: >>>>> On Fri, Mar 25, 2022 at 12:01 AM Peter Eisentraut >>>>> <peter.eisentr...@enterprisedb.com> wrote: >>>>> Or even: Why are we exposing fork *numbers* in the user interface? >>>>> Even low-level tools such as pageinspect use fork *names* in their >>>>> interface. >>>> >>>> I wondered about that but thought it seemed OK for such a low level >>>> tool. It's a fair point though, especially if other low level tools >>>> are doing that. Here's a patch to change it. >>> >>> Oh, and there's already a name lookup function to use for this. >> >> +1 on the semantic names. > > Cool. > > I had another thought while changing that (and also re-alphabetising): > Why don't we switch to -B for --block and -R for --relation? I > gather you used -k and -l because -b and -r were already taken, but > since we already started using upper case for -F, it seems consistent > this way. Or were they chosen for consistency with something else?
Works here; was just trying to get semi-memorable ones from the available lowercase ones, but I like your idea here, and it kind of puts them in the same mental space for remembering. > It's also slightly more helpful to a user if the help says > --relation=T/D/R instead of N/N/N (TS/DB/REL would be nicer but > doesn't fit in the space).
0001-Improve-command-line-switches-in-pg_waldump-option.patch
Description: Binary data
