Re: pg_dump --with-* options

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Álvaro Herrera <alvherre(at)kurilemu(dot)de>, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_dump --with-* options
Date: 2025-07-30 15:04:17
Message-ID: cf21ea99caa39e89d26b8d83d78610db8938bdba.camel@j-davis.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 2025-07-30 at 10:23 +0200, Álvaro Herrera wrote:
> Maybe we should invent a new
> switch, something like
>   --include=[schema,data,statistics]
> with which users can give one or more comma-separated types to be
> included in the dump. 

Robert Treat brought up a similar idea before:

https://www.postgresql.org/message-id/CABV9wwO5v8Nu8q%2BxWexMdL3Z%2B2xS%3DfFJMQetBSHy3tR64wNHOA%40mail.gmail.com

I'm certainly open to (re-)considering it.

> Then we state that --data-only is synonym for --include=data and
> --schema-only is synonym for --include=schema, and we don't need any
> other switches.  Then it is obvious what happens, how to combine
> object types in the dumps and restores, and there's no need to reject
> invalid combinations because there aren't any.

I assume that should be read as something like "include only", because
--include=data would also be excluding the schema and the stats. And if
that's the case, it does seem strange to do something like "--
include=data --schema-only".

Another question: could you have multiple --include options, like "--
include=data --include=schema"? Because you currently can't do "--data-
only --schema-only". So that would make it not quite an alias.

If we go in this direction, it might be easier to just say that --
include conflicts with --schema-only and --data-only.

Regards,
Jeff Davis

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2025-07-30 15:10:16 Re: Support getrandom() for pg_strong_random() source
Previous Message Tom Lane 2025-07-30 13:34:58 Re: Improve prep_buildtree