Re: pg_ctl command option anomalies

On Thu, Apr 20, 2017 at 4:20 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Neha Khatri <nehakhatri5(at)gmail(dot)com> writes:
> > On Thu, Apr 20, 2017 at 3:53 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> Um ... all of those except -c and -w require an argument AFAIK. Where
> did
> >> you read that they don't?
>
> > I did not mean that they don't require an argument. What I was trying to
> > refer is that "pg_ctl status" would not require a "-m fast", for
> instance.
>
> Ah. Yeah, pg_ctl doesn't bother to complain about options that are
> irrelevant to the selected sub-command. But they still have to be
> syntactically valid. For instance, "-m bogus" would be rejected whether
> or not -m is relevant to the selected sub-command.
>

But this looks odd, when I am not trying to shutdown, I am just checking
the status:
$ pg_ctl status -D data/ -m abc
pg_ctl: unrecognized shutdown mode "abc"
Try "pg_ctl --help" for more information.

> There's a pretty large amount of art and history behind the way that
> Unix commands react to command-line options. One thing that's gotten
> worked out along the way is that failing because some option is irrelevant
> to the specific current action is really not very helpful. For example,
> C compilers generally allow -I options even when the current action only
> involves linking not compiling, or -L options in the reverse case, because
> doing otherwise makes Makefile-writing a lot harder for little benefit.
> There are C compilers that just issue a warning (not fail outright) for
> "unused command line options" in such cases, but even that is widely
> deemed to be unhelpful pedantry.
>

That's enlightening.

Regards,
Neha