On Wed, Oct 2, 2024 at 6:00 AM Daniel Westermann (DWE) <daniel.westerm...@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
