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