On Tuesday, March 31, 2026, Tom Lane <[email protected]> wrote:

> "David G. Johnston" <[email protected]> writes:
> > But how about adding something like the following to the pg_dump notes?
> We
> > already have the corresponding link going to pg_dump in the pg_restore
> > notes.
>
> > "If producing a non-plaint-text format output see also the pg_restore
> > documentation for details on how the restore process uses the different
> > sections."
>
> Hmm, I think we could be a bit more definite than that.  What do you
> think of this advice:
>
>   <para>
>    When creating an archive (non-text) output file, it is advisable not to
>    restrict the set of database objects dumped, but instead plan to apply
>    any desired object filtering when reading the archive
>    with <application>pg_restore</application>.  This will preserve
>    flexibility and possibly avoid problems at restore time; for details
>    see the <xref linkend="app-pgrestore"/> documentation.  However,
>    omitting table data (<option>--no-data</option>) or large objects
>    (<option>--no-large-objects</option>) does not have any surprising
>    consequences.
>   </para>
>
>
I’m against including that final sentence.  The rest seems ok but I’
suggest going with an explicit mention that “—no-schema is risky” (or
otherwise omitting the entire section)

I have a nagging suspicion we could be a bit more precise; e.g., it’s
advisable to include the schema objects for the data that is being exported
only, not the entire schema always.  But we already mention that dealing in
subsets can introduce dependency issues so people have already been given
the alert there.  But data/no-schema seems like it should just work and
this just needs to warn them that it may not.

David J.

Reply via email to