Re: pg_dumpall --roles-only interact with other options - Mailing list pgsql-hackers

On Thu, Feb 5, 2026 at 2:33 AM Nathan Bossart <nathandbossart@gmail.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/