Re: pg_basebackup and error messages dependent on the order of the arguments - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_basebackup and error messages dependent on the order of the arguments
Date
Msg-id 449352.1727983951@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_basebackup and error messages dependent on the order of the arguments  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> 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:
> ...
> I assume there are similar cases that don't involve PostgreSQL at all.

Yeah.  This has to be a standard problem for anything that uses getopt
or getopt_long at all.  Unless there's a standard approach (which I've
not heard of) to resolving these ambiguities, I'm not sure that we
should try to outsmart everybody else.

In the case of getopt_long there's an additional problem, which is
that that function itself may contain heuristics that rearrange the
argument order based on what looks like a switch or not.  It's likely
that anything we did on top of that would behave differently depending
on which version of getopt_long it is.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: pg_basebackup and error messages dependent on the order of the arguments
Next
From: Andres Freund
Date:
Subject: Re: bgwrite process is too lazy