a couple of small cleanup patches for DSM-related code
0001 changes test_dsm_registry.c to use PG_GETARG_INT32 and
PG_RETURN_INT32. The installation script and the C code both used signed
integers, so I'm not sure why I used PG_GETARG/RETURN_UINT32 in commit
8b2bcf3. I'm planning to back-patch this one to v17, where the DSM
registry was first introduced.
0002 follows commit 5fe08c0's example and changes some calls to
dshash_attach() and dsa_create_in_place() to use NULL instead of 0 for
pointer arguments. I don't see any need to back-patch this one, but I also
don't see any need to wait for v19devel to commit it.
Any objections?
--
nathan
On Wed, Jun 4, 2025 at 12:48 PM Nathan Bossart <nathandbossart@gmail.com> wrote:
0001 changes test_dsm_registry.c to use PG_GETARG_INT32 and
PG_RETURN_INT32. The installation script and the C code both used signed
integers, so I'm not sure why I used PG_GETARG/RETURN_UINT32 in commit
8b2bcf3. I'm planning to back-patch this one to v17, where the DSM
registry was first introduced.
+1
0002 follows commit 5fe08c0's example and changes some calls to
dshash_attach() and dsa_create_in_place() to use NULL instead of 0 for
pointer arguments. I don't see any need to back-patch this one, but I also
don't see any need to wait for v19devel to commit it.
It seems okay to me to commit it to HEAD as it's a cosmetic change and
improves the consistency between v18 and 19.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
On Wed, Jun 04, 2025 at 01:53:06PM -0700, Masahiko Sawada wrote:
It seems okay to me to commit it to HEAD as it's a cosmetic change and
improves the consistency between v18 and 19.
Right. It looks confusing to leave these at 0 rather than NULL as
they mean a pointer, for the same reasons as what you have documented
in 5fe08c006c82. Doing that now or waiting for v19 does not make much
difference. Anyway, there's always the less-noise-when-backpatching
argument, so if you apply that now on HEAD that's fine IMO.
--
Michael