Re: Why does pg_checksums -r not have a long option?

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Why does pg_checksums -r not have a long option?
Date: 2019-05-27 06:32:21
Message-ID: alpine.DEB.2.21.1905270819080.24257@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hello Michael-san,

> No objections with adding a long option for that stuff. But I do have
> an objection with the naming because we have another tool able to work
> on relfilenodes:
> $ oid2name --help | grep FILE
> -f, --filenode=FILENODE show info for table with given file node
>
> In this case, long options are new as of 1aaf532 which is recent, but
> -f is around for a much longer time.
>
> Perhaps we should use the same mapping for consistency?
>
> pg_verify_checksums has been using -r for whatever reason, but as we
> do a renaming of the binary for v12 we could just fix that
> inconsistency as well. Hence I would suggest that for the option
> description:
> "-f, --filenode=FILENODE"

Fine with me, I was not particularly happy with "relfilenode", but just
picked it up for consistency with -r.

> I would also switch to the long option name in the tests at the same
> time, this makes the perl scripts easier to follow.

Ok. Attached.

I've used both -f & --filenode in the test to check that the renaming was
ok. I have reordered the options in the documentation so that they appear
in alphabetical order, as for some reason --progress was out of it.

--
Fabien.

Attachment Content-Type Size
checksums-long-option-2.patch text/x-diff 6.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2019-05-27 06:41:50 Re: Excessive memory usage in multi-statement queries w/ partitioning
Previous Message Alex 2019-05-27 06:01:34 some questions about fast-path-lock