Re: pg_dump --with-* options

From: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_dump --with-* options
Date: 2025-07-11 00:12:02
Message-ID: b1e217e4-0527-48ba-9d8a-74106d47f216@oss.nttdata.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2025/07/11 2:57, Jeff Davis wrote:
> On Wed, 2025-06-25 at 08:18 +0900, Fujii Masao wrote:
>> For pg_dump and pg_dumpall, I agree with Jeff's idea in [1],
>> but if the statistics is skipped by default, I don't think
>> we need a --no-statistics option. So, here's how I think
>> the options should work:
>>
>>      * Keep: --schema-only, --data-only, --statistics-only, --no-
>> schema, --no-data, -and -statistics
>>      * Remove: --no-statistics, --with-schema, and --with-data
>
> ...
>
>> For pg_restore, I believe there's agreement to restore statistics
>> by default if they exist in the archive. So:
>>
>>      * Keep: --schema-only, --data-only, --statistics-only, --no-
>> schema, --no-data, and --no-statistics
>>      * Remove: --with-schema, --with-data, and --statistics
>
> That means pg_dump will accept --statistics and reject --no-statistics;
> and pg_restore will accept --no-statistics and reject --statistics.
> Other options are mostly the same between them, so I'm not sure it's a
> good idea for them to diverge.

I agree it would be better to have the same options in both pg_dump
and pg_restore, if possible.

But to do that, we'd either need to make pg_dump dump statistics
by default, or allow redundant options like --statistics in pg_restore,
even though it already restores statistics by default.

As I understand it, the rough consensus so far is that we'd prefer to
avoid both of these approaches. I know some want to change the default
behavior about statistics in pg_dump, though.

But, are you suggesting we go with one of them?

Regards,

--
Fujii Masao
NTT DATA Japan Corporation

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2025-07-11 01:47:04 Re: PG18 protocol version
Previous Message Nikolay Samokhvalov 2025-07-10 23:50:33 docs: LISTEN/NOTIFY performance considerations