Re: pg_dump, pg_basebackup don't error out with wrong option for "--format"

From: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
To: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_dump, pg_basebackup don't error out with wrong option for "--format"
Date: 2021-11-25 05:32:04
Message-ID: CAFiTN-tWuDWm4dbCMVVWMz-zVRmh2PRrMn+QLq=ipexsFn-UqA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Nov 25, 2021 at 10:44 AM Bharath Rupireddy
<bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
>
> Hi,
>
> I noticed that the pg_dump and pg_basebackup are not erroring out when
> "--fo"/"--for"/"--form"/"--forma"/" are specified(use cases 1 - 4, 7 -
> 9) whereas it fails if a pattern that doesn't match with "format" is
> specified (use case 5, 10). This seems to be true only for "--format"
> option, for other options it just errors out (use case 6). Why is the
> behaviour for "--format" isn't consistent?
>
> Is it something expected? Is the option parsing logic here buggy?

I think for parsing we use getopt_long(), as per that if you use the
prefix of the string and that is not conflicting with any other option
then that is allowed. So --fo, --for all are accepted, --f will not
be accepted because --file and --format will conflict, --foo is also
not allowed because it is not a valid prefix string of any valid
option string.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2021-11-25 05:52:11 Re: pg_dump, pg_basebackup don't error out with wrong option for "--format"
Previous Message Dilip Kumar 2021-11-25 05:14:53 Re: [BUG]Missing REPLICA IDENTITY check when DROP NOT NULL