Re: pg_dump --with-* options

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Jeff Davis <pgsql(at)j-davis(dot)com>, Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_dump --with-* options
Date: 2025-06-13 05:22:13
Message-ID: 2ca8a35d-4bba-4529-88c1-3ca92dbc9e87@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12.06.25 23:20, Jeff Davis wrote:
> On Thu, 2025-06-12 at 21:16 +0200, Peter Eisentraut wrote:
>>> Do we have other options that are order-sensitive?
>>
>> I think most of them are.  For example:
>>
>> psql -p 5432 -p 5433
>> initdb --data-checksums --no-data-checksums
>> postgres --shared-buffers=1GB --shared-buffers=2GB
>
> Interesting. I don't think the "last option wins" model applies to
> other pg_dump options, though. For instance, in PG17:
>
> pg_dump --data-only --schema-only
> pg_dump: error: options -s/--schema-only and -a/--data-only cannot be
> used together
>
> I don't think it's simple to start using "last option wins" behavior
> now. There are probably some combinations of options where it's not
> clear whether a later option is an extra constraint or will override a
> previous option.

It makes sense to raise an error if the specified options cannot be
consolidated in an obvious way. I'd expect

pg_recvlogical --create-slot --drop-slot

to fail, but I'd expect

pg_recvlogical --create-slot --slot=foo --slot=bar

to work.

One of the challenges in the current case is that it is not obvious how
--with-data, --no-data, --data-only etc. are connected. If that were
clearer, then the way these options should combine or conflict would
hopefully follow somewhat naturally.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Steven Niu 2025-06-13 05:41:10 Re: Support tid range scan in parallel?
Previous Message Pavel Stehule 2025-06-13 04:53:20 Re: proposal: schema variables