Re: [PATCH] add relation and block-level filtering to pg_waldump

> On Mar 24, 2022, at 4:12 PM, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
>
> On Fri, Mar 25, 2022 at 1:43 AM David Christensen
> <david(dot)christensen(at)crunchydata(dot)com> wrote:
>>>> On Mar 24, 2022, at 6:43 AM, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
>>> On Fri, Mar 25, 2022 at 12:26 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
>>>>> On Fri, Mar 25, 2022 at 12:01 AM Peter Eisentraut
>>>>> <peter(dot)eisentraut(at)enterprisedb(dot)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).