From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Mats Kindahl <mats(at)timescale(dot)com> |
Cc: | Aleksander Alekseev <aleksander(at)timescale(dot)com>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net> |
Subject: | Re: Coccinelle for PostgreSQL development [1/N]: coccicheck.py |
Date: | 2025-01-19 01:10:05 |
Message-ID: | Z4xQ7YuOugZIMvIg@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Jan 18, 2025 at 08:44:00PM +0100, Mats Kindahl wrote:
> For PostgreSQL 16, Peter extended the palloc()/pg_malloc() interface in
> commit 2016055a92f to provide more type-safety, but these functions are not
> widely used. This semantic patch captures and replaces all uses of palloc()
> where palloc_array() or palloc_object() could be used instead. It
> deliberately does not touch cases where it is not clear that the
> replacement can be done.
I am not sure how much a dependency to coccicheck would cost (usually
such changes should require a case-by-case analysis rather than a
blind automation), but palloc_array() and palloc_object() are
available down to v13.
Based on this argument, it would be tempting to apply this rule
across the stable branches to reduce conflict churn. However this is
an improvement in readability, like the talloc() things as Peter has
mentioned, hence it should be a HEAD-only thing. I do like the idea
of forcing more the object-palloc style on HEAD in the tree in some
areas of the code, even if it would come with some backpatching cost
for existing code.
Thoughts? Perhaps this has been discussed previously?
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2025-01-19 04:49:48 | Re: Re:Limit length of queryies in pg_stat_statement extension |
Previous Message | Peter Smith | 2025-01-19 01:09:11 | Re: Pgoutput not capturing the generated columns |