| From: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> |
|---|---|
| To: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Mark function arguments of type "T *" as "const T *" where possible |
| Date: | 2025-12-12 14:33:39 |
| Message-ID: | aTwnw+4ubvsdqeM5@ip-10-97-1-34.eu-west-3.compute.internal |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
> <bertranddrouvot(dot)pg(at)gmail(dot)com> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2025-12-12 14:46:33 | Re: proposal: schema variables |
| Previous Message | Arunprasad Rajkumar | 2025-12-12 14:26:10 | [PATCH] Skip unpublishable child tables when adding parent to publication |