Re: pg_basebackup and error messages dependent on the order of the arguments

On Wed, Oct 2, 2024 at 6:00 AM Daniel Westermann (DWE)
<daniel.westermann@dbi-services.com> wrote:
> Maybe checking if a valid "-D" or "--pgdata" was given and return a more generic error message would be an option?

It doesn't really seem reasonable to me to make the tools guess
whether somebody left out the argument to an option that requires an
argument. Consider these equivalent cases:

$ pg_dump -t -Ft
pg_dump: error: no matching tables were found
$ initdb -c --text-search-config=english -D x
<lots of output>
running bootstrap script ... 2024-10-03 18:56:51.372 GMT [16909] LOG:
syntax error in file "/Users/robert.haas/pgsql/x/postgresql.conf" line
843, near token "-"
2024-10-03 18:56:51.372 GMT [16909] FATAL:  configuration file
"/Users/robert.haas/pgsql/x/postgresql.conf" contains errors
child process exited with exit code 1
initdb: removing data directory "x"
$ dropuser -h -e bob
dropuser: error: could not translate host name "-e" to address:
nodename nor servname provided, or not known

I assume there are similar cases that don't involve PostgreSQL at all.
I think that this kind of problem is basically normal and the code is
working as designed. It's true that in some cases we could maybe make
an intelligent guess that the user has messed up, but that's always
got to be based on knowing that something that is formally an option
to an argument looks more like a separate argument. And I'm just not
very enthusiastic about inserting heuristics like that all over the
place. It seems like a lot of work and hard to get right, and it could
easily end up being more annoying than useful, if say we accidentally
reject something that was truly intended to be an argument to the
switch rather than a second argument.

--
Robert Haas
EDB: http://www.enterprisedb.com