Re: [PATCH] Unify duplicate-option handling across utility commands - Mailing list pgsql-hackers

From Baji Shaik
Subject Re: [PATCH] Unify duplicate-option handling across utility commands
Date
Msg-id CA+fm-RNVtpR+wJXMWuNCSYOHu9KbuxTj-Jnyc2jP3wbaNToX4g@mail.gmail.com
Whole thread
In response to [PATCH] Unify duplicate-option handling across utility commands  (Baji Shaik <baji.pgdev@gmail.com>)
List pgsql-hackers


On Wed, Oct 7, 2026 at 1:31 PM Álvaro Herrera <alvherre@kurilemu.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. 

pgsql-hackers by date:

Previous
From: Alexandre Felipe
Date:
Subject: Re: LWLock granular partition lock memory layout
Next
From: shihao zhong
Date:
Subject: Re: Parallel autovacuum: DROP DATABASE WITH (FORCE) fails on the parallel workers