Re: BUG #19042: Option --help not recognized at the end of command line in pg_restore

Daniel Gustafsson <daniel@yesql.se>

From: Daniel Gustafsson <daniel@yesql.se>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Peter Eisentraut <peter@eisentraut.org>, Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>, Matthias Hörmann <matthias.hoermann@saltation.com>, pgsql-bugs@lists.postgresql.org
Date: 2025-10-27T19:49:06Z
Lists: pgsql-bugs
> On 27 Oct 2025, at 16:30, Nathan Bossart <nathandbossart@gmail.com> wrote:

Thanks for review!

> On Sat, Oct 25, 2025 at 12:26:01AM +0200, Daniel Gustafsson wrote:
>> While hacking on this it seemed like a good idea to move to using progname
>> consistently, and reduce scope in some places from global variables, but
>> looking at it now I'm less convinced.  At the very least it should be ripped
>> out into its own patch but for now those changes are left in there.
> 
> Yeah, that does feel like it ought to be its own patch.

Absolutely agree, will move that out in the next version.

> After a
> read-through, 0001 looks like the right idea to me, though.  It's a larger
> patch, but the majority of the changes are pretty mechanical.

It’s indeed pretty boring, and considering what the patch want to achieve I guess that’s a good thing.

> +/* port/pg_option_utils.c */
> +extern bool is_help_param(int argc, char *argv[], int optind);
> 
> And fe_utils/option_utils.c, right (since it has a copy of this function)?
> Or is the idea to use pg_option_utils.c for both the frontend and the
> backend?

I originally placed it in fe_utils but then moved to src/port to avoid adding libpq depesencies where we dont have them today. If there is a second copy then I missed that in my rebase (am travelling without laptop so cant comfortably read patches right now to check). Not sure what the best option is and how big of a deal it is. Do you have any suggestions?

./daniel