Re: pg_dump, pg_basebackup don't error out with wrong option for "--format"
От | Dilip Kumar |
---|---|
Тема | Re: pg_dump, pg_basebackup don't error out with wrong option for "--format" |
Дата | |
Msg-id | CAFiTN-tWuDWm4dbCMVVWMz-zVRmh2PRrMn+QLq=ipexsFn-UqA@mail.gmail.com обсуждение исходный текст |
Ответ на | pg_dump, pg_basebackup don't error out with wrong option for "--format" (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>) |
Ответы |
Re: pg_dump, pg_basebackup don't error out with wrong option for "--format"
|
Список | pgsql-hackers |
On Thu, Nov 25, 2021 at 10:44 AM Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.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
В списке pgsql-hackers по дате отправления: