| From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
|---|---|
| To: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Remove unused function parameters, part 2: replication |
| Date: | 2025-12-04 09:34:34 |
| Message-ID: | 17D5EDB6-F39F-45DF-90E4-60AD669E23AE@yesql.se |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On 2 Dec 2025, at 15:28, Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Yilin Zhang | 2025-12-04 09:40:57 | Re:Re: pg_recvlogical: Prevent flushed data from being re-sent after restarting replication |
| Previous Message | David Geier | 2025-12-04 09:31:41 | Re: Consistently use palloc_object() and palloc_array() |