Re: Remove unused function parameters, part 2: replication - Mailing list pgsql-hackers

From Daniel Gustafsson
Subject Re: Remove unused function parameters, part 2: replication
Date
Msg-id 17D5EDB6-F39F-45DF-90E4-60AD669E23AE@yesql.se
Whole thread Raw
In response to Re: Remove unused function parameters, part 2: replication  (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>)
Responses Re: Remove unused function parameters, part 2: replication
List pgsql-hackers
> On 2 Dec 2025, at 15:28, Bertrand Drouvot <bertranddrouvot.pg@gmail.com> wrote:

> That said I'm still skeptical that we need to provide a strong
> justification (as the one above) to remove an unused parameter.

If it breaks an existing published API thus causing extensions to fail to
compile then IMHO that's a pretty strong argument against removing a parameter
even if it's unused, likewise if the change can be expected to cause
backpatching conflicts for the coming five years.  For static functions at
least it seems that compilers are fairly happy to remove the parameter in
greater than -O0 levels (though I know that won't move the needle on one of
your main drivers being readability).

--
Daniel Gustafsson




pgsql-hackers by date:

Previous
From: David Geier
Date:
Subject: Re: Consistently use palloc_object() and palloc_array()
Next
From: "Yilin Zhang"
Date:
Subject: Re:Re: pg_recvlogical: Prevent flushed data from being re-sent after restarting replication