Re: pg_ctl command option anomalies

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neha Khatri <nehakhatri5(at)gmail(dot)com>
Cc: pgsql-novice(at)postgresql(dot)org
Subject: Re: pg_ctl command option anomalies
Date: 2017-04-20 06:20:40
Message-ID: 21300.1492669240@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-novice

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.

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

In response to

Responses

Browse pgsql-novice by date

  From Date Subject
Next Message Neha Khatri 2017-04-20 07:07:56 Re: pg_ctl command option anomalies
Previous Message Neha Khatri 2017-04-20 06:05:45 Re: pg_ctl command option anomalies