Re: [PATCH] Unify duplicate-option handling across utility commands

From: Baji Shaik <baji(dot)pgdev(at)gmail(dot)com>
To: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
Cc: PostgreSQL-development <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH] Unify duplicate-option handling across utility commands
Date: 2026-10-07 19:34:55
Message-ID: CA+fm-RNVtpR+wJXMWuNCSYOHu9KbuxTj-Jnyc2jP3wbaNToX4g@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 7, 2026 at 1:31 PM Álvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:

> On 2026-Oct-07, Baji Shaik wrote:
>
> Oh, it was? I don't remember that -- where is that?

That was commit a120ecf5498 ("Fix parsing of REPACK options"), which
made REPACK honor the last value when an option is repeated.

> I don't think last-wins is our norm, or is it?
>

Right, most commands that take a DefElem option list reject duplicates
via errorConflictingDefElem() (COPY, WAIT FOR, CREATE/ALTER ROLE and
SUBSCRIPTION, CREATE DATABASE, etc.).
my thought process was like these are maintenance-style commands
(VACUUM, ANALYZE, EXPLAIN, CHECKPOINT, REPACK) and are last-wins, so
I went in that direction thinking of them as one group that behaves the
same way.

So if the goal is to unify across the board, I'm happy to go with
rejection instead and make the maintenance commands reject duplicates too,
which matches the majority. I can redo the patch that way.

Thanks,
Baji Shaik.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message shihao zhong 2026-10-07 19:37:55 Re: Parallel autovacuum: DROP DATABASE WITH (FORCE) fails on the parallel workers
Previous Message Alexandre Felipe 2026-10-07 19:22:38 Re: LWLock granular partition lock memory layout