Re: pg_dumpall --roles-only interact with other options

On Thu, Feb 5, 2026 at 2:33 AM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
> I'm not following your objection here. If anything, such a change would
> reduce complexity. For example, we currently use the following check in
> multiple places to decide whether to drop/drump databases:
>
> if (!globals_only && !roles_only && !tablespaces_only)
>
> If we created a derivative flag like this:
>
> shouldDumpDBs = !globals_only && !roles_only && !tablespaces_only;
>
> We could then decide whether to do database things like this:
>
> if (shouldDumpDBs)
> dumpDatabases(conn);
>
> This has the added benefit of simplifying future patches that add new -only
> options. If/when that happens, we'd just add it to the line that sets
> shouldDumpDBs, whereas today we'd need to go through the rest of the code
> and update multiple conditions. Not to mention the readability
> improvements...

I thought you meant to add a new field to DumpOptions.

I've added 3 bool variables: shouldDumpDBs, shouldDumpTablespaces,
shouldDumpRoles.
shouldDumpDBs = !globals_only && !roles_only && !tablespaces_only;
shouldDumpTablespaces = !roles_only && !no_tablespaces &&
!data_only && !schema_only && !statistics_only;
shouldDumpRoles = !tablespaces_only && !data_only && !schema_only
&& !statistics_only;

pg_dumpall --statistics
will dump global objects, data, schema, and statistics.
Which is correct, I think.

>
> + /* reject conflicting "-only" options */
> + if (globals_only && with_statistics)
> + pg_fatal("options %s and %s cannot be used together",
> + "-g/--globals-only", "--statistics");
> + if (globals_only && statistics_only)
> + pg_fatal("options %s and %s cannot be used together",
> + "-g/--globals-only", "--statistics-only");
>
> As before, I think we should integrate the new conflicting option handling
> into the existing section that does this sort of thing. We should also
> make sure the handling is the same. The existing code uses pg_log_error(),
> pg_log_error_hint(), and exit_nicely(), while the patch uses pg_fatal().
>

Adding a pg_log_error_hint would likely be helpful, since the reason
for the failure is not very intuitive,

The attached patch also addresses the points mentioned by Zsolt Parragi.

I just found out
pg_dumpall --no-data --data-only
will not immediately fail, it will fail during pg_dumpall call pg_dump.
not sure if this is ok or not.

--
jian
https://www.enterprisedb.com/