| From: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> | 
|---|---|
| To: | Mats Kindahl <mats(dot)kindahl(at)gmail(dot)com> | 
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org | 
| Subject: | Re: Coccinelle for PostgreSQL development [1/N]: coccicheck.py | 
| Date: | 2025-11-03 09:55:02 | 
| Message-ID: | aQh79jMqU7mq03Hv@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, Oct 30, 2025 at 02:32:45PM +0100, Mats Kindahl wrote:
> Hi all,
> 
> Here is an updated set of patches based on the latest HEAD of PostgreSQL.
Thanks for those patches and the initiative! Sorry to be late, I started
to look at Coccinelle "for PostgreSQL" in [1] (to ensure some macros are used)
and saw this thread.
I did not look at the patches in detail, but sharing some thoughts.
I agree that Coccinelle could be/is useful in relation to PostgreSQL development,
but I think that we'd need to determine why it would useful to add the
coccicheck.py script and the new dependencies in autoconf/meson.
Coming back to your points and thinking if it could be used as a tool or integrated
into the build system:
1) Identify and correct bugs in the source code both during development and
review
I agree that makes sense here. Having some bugs detected "automatically" would
be great.
2) Make large-scale changes to the source tree to improve the code based on
new insights
I'm not sure we need to introduce coccicheck.py and add dependencies in
autoconf/meson for this. The developer would need to know that he could use
the Coccinelle and if he already knows then nothing prevents him from using it
in his development tool box.
3) Encode and enforce APIs by ensuring that function calls are used
correctly
Same as 2) That said we could also imagine running yearly checks automatically
too using coccicheck.py.
4) Use improved coding patterns for more efficient code
Same as 3) from my point of view.
5) Allow extensions to automatically update code for later PostgreSQL
versions
Same as 2) from my point of view.
So, I think that the current proposal (i.e build system integration) is a good
fit for 1), less so for 3) and 4) and not necessarily needed for 2) and 5).
The proposal will add new dependencies (as Michael stated up-thread) and introduce
a new language (SmPL) that folks would need to be comfortable with to review
the .cocci scripts.
I don't have an answer to it but I think that the main question is: Should we
integrate this into the build system, or just document it as an optional
developer tool (wiki or such and provide .cocci scripts example)?
[1]: https://www.postgresql.org/message-id/aQMtR/m4kW4Rkul%2B%40ip-10-97-1-34.eu-west-3.compute.internal
Regards,
-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2025-11-03 10:27:38 | Re: Use stack-allocated StringInfoData | 
| Previous Message | shveta malik | 2025-11-03 09:54:54 | Re: Report bytes and transactions actually sent downtream |