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 |
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 |