Re: unrecognized option '--help

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, "D(dot) S(dot)" <spider(at)skuggor(dot)se>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: unrecognized option '--help
Date: 2015-05-22 03:59:21
Message-ID: 20150522035921.GT5885@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:

> > I don't think it really is the symptom complained about here. Right now
> > "vacuumdb dbname --verbose" works (i.e. recognizes verbose as an
> > option), whereas "vacuumdb dbname --help" doesn't. The latter is what's
> > complained about here. And the reason for that is that
> > --help/-?/--version/-v aren't part of the getopt_long() call.
>
> Meh. I don't particularly object to including --help in the switch set
> recognized in getopt_long ... but I doubt that that will actually fix
> Alvaro's scenario.

Nah, I think that's okay for my usage.

> Note that we should not rip out the existing code, because part of the
> reason for that is that it acts before any of the other stuff that runs
> before getopt parsing starts, eg the postmaster's refusal to run if you're
> root.

No objection to that, though I wonder (without looking at the code) if
for binaries other than postmaster this is really worthwhile.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2015-05-22 06:13:07 Re: unrecognized option '--help
Previous Message Tom Lane 2015-05-22 02:24:57 Re: unrecognized option '--help