Re: Why pg_dump overwrites dump file? - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Why pg_dump overwrites dump file?
Date
Msg-id aQJhTLEIF3FUOYBD@momjian.us
Whole thread Raw
In response to Re: Why pg_dump overwrites dump file?  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: Why pg_dump overwrites dump file?
List pgsql-hackers
On Tue, Oct 14, 2025 at 10:44:37AM +0200, Daniel Gustafsson wrote:
> Another inconsistency is that the documentation states this:
> 
>     "In this case the directory is created by pg_dump and must not exist
>     before."
> 
> ..which isn't true, since it will happily reuse an existing directory as long as
> it's empty, the comment in the code makes the intention clear:
> 
>   /*
>    * create_or_open_dir
>    *
>    * This will create a new directory with the given dirname. If there is
>    * already an empty directory with that name, then use it.
>    */
> 
> So regardless it seems we should something like the attached at least.
> 
> --
> Daniel Gustafsson
> 

> diff --git a/doc/src/sgml/ref/pg_dump.sgml b/doc/src/sgml/ref/pg_dump.sgml
> index fd4ecf01a0a..5ac3f3e8510 100644
> --- a/doc/src/sgml/ref/pg_dump.sgml
> +++ b/doc/src/sgml/ref/pg_dump.sgml
> @@ -297,8 +297,8 @@ PostgreSQL documentation
>          file based output formats, in which case the standard output is used.
>          It must be given for the directory output format however, where it
>          specifies the target directory instead of a file. In this case the
> -        directory is created by <command>pg_dump</command> and must not exist
> -        before.
> +        directory is created by <command>pg_dump</command> unless the directory
> +        exist and is empty.
>         </para>
>        </listitem>
>       </varlistentry>

Uh, Daniel, are you going to make this change?

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: PG18 GIN parallel index build crash - invalid memory alloc request size
Next
From: Jeff Davis
Date:
Subject: Re: C11: should we use char32_t for unicode code points?