Hi, On Thu, Dec 11, 2025 at 09:51:49AM -0800, Jacob Champion wrote: > On Wed, Dec 10, 2025 at 11:22 PM Bertrand Drouvot > <[email protected]> wrote: > > Let me try to focus on functions that really > > deserve the change. I could look at function names that contain "copy" or > > "cmp", > > functions that are used for formatting/printing and size/length > > calculations as > > examples. > > Sure, that sounds reasonable, and I would hope that those sorts of > functions are not very high on the list of backport contention.
So, with a filter like: "^.*(cmp|copy|Cmp|Copy|Control|control|Check|check|Size|size|Length|length).*$"; (maybe other filters will come to mind) that gives: 36 files changed, 92 insertions(+), 78 deletions(-) I did not check the details, just the repartition and that gives: cmp: 3 functions copy: 18 control: 1 check: 35 size: 15 length: 2 The numbers are more manageable. Maybe be could put check, copy and size in their own patches and put the remaining in a 4th one? (and I'd look closely if the changes make sense based on the function name and content, means the const addition has a "real" intent i.e not just a technical one). > > Any other ideas? > > Just that the most useful const additions (IMHO) are going to be > places at the top of a big hierarchy, where callers expect something > not to be modified, but the lowest levels are too far removed from > that expectation for developers to easily remember. I think that's a good idea, thanks! > I imagine those > cases are not going to be easy to find automatically (but that > shouldn't discourage incremental improvements that can be found that > way). Yeah, will git it a try though. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
