Обсуждение: [NOVICE] pg_ctl command option anomalies

Neha Khatri <nehakhatri5@gmail.com> writes:
> Some of the pg_ctl modes do not require following options:
>   -m, -w, -t, -c, -l, -o, -p

Um ... all of those except -c and -w require an argument AFAIK.  Where did
you read that they don't?

The pg_ctl man page does seem to need some work, for instance -t is shown
as requiring an argument in the syntax synopsis, and the textual
description implies that it has one, but

-t
--timeout

should look more like

-t seconds
--timeout=seconds

But on the whole I'd bet that discrepancies of this sort are documentation
bugs not code bugs.

            regards, tom lane

Neha Khatri <nehakhatri5@gmail.com> writes:
> On Thu, Apr 20, 2017 at 3:53 PM, Tom Lane <tgl@sss.pgh.pa.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.

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.

            regards, tom lane