On Mon, Dec 01, 2025 at 06:49:25AM +0000, Bertrand Drouvot wrote:
> We can still continue to fix them when we cross them "accidentally".
>
> That said, it somehow sounds weird to wait to cross them accidentally knowing we
> have the tool to find them, so I'm still not convinced that just ignoring them
> is the right thing to do.
There are a couple of concepts that usually come in the balance here.
For example, in some cases, we may not want to remove function
arguments because it can make API definitions more consistent across
the board, aka leaner for the reader. It may be also possible that
having these function arguments lying around could help in future
backpatches, not to mention that it reduces the chances of conflicts.
Andres' arguments are on this side of the balance, as far as I
understand.
An argument that can argue in favor of a removal is if this simplifies
the stack of functions calling the function where the removal happens.
Simple example I have seen in the past: a Relation argument not used
(I think there has been at least one such example in tablecmds.c,
whatever). Removing this argument also meant that we don't require
function callers to open a Relation, removing the need to think about
the lock it would require at open. In such a case, removing an
argument has more value than what a script detects, even more if this
routine is published in a header, as it could be called by some
out-of-core extension code, or in a fork.
--
Michael
