Remove traces of long in dynahash.c
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-08-19T06:24:39Z
Lists: pgsql-hackers
Attachments
- 0001-Replace-uses-of-long-by-uint64-in-dynahash.c-and-hse.patch (text/x-diff) patch 0001
Hi all, While looking at the recent business with dynahash.c in [1], I have been reminded of the fact that this code still depends on long. Based on my lookup of the code, I don't think that there is any issue with the current uses, but I've never been a fan of using a type that's 8 byte everywhere except on WIN32, and we have been bitten by that in the past depending on the code paths where long is used, even if WIN32 should be niche these days. So I have looked at this file, and finished with the attached. The result is nice, removing long from hsearch.h, as well as dynahash.c, cleaning up some variable declarations on the way. While monitoring the callers of the function signatures updated in this patch, there is a mix of Size, int or int32 used in the variable declarations used with the callers. There were a couple of long declared in a couple of places like pgss, locking, predicate, shmem that were declared as such to map with dynahash. These can be replaced. Thoughts? [1]: https://www.postgresql.org/message-id/aKF8mPDqgQb3uBjG@paquier.xyz -- Michael
Commits
-
Remove dynahash.h
- e6da68a6e1d6 19 (unreleased) landed
-
Replace callers of dynahash.h's my_log() by equivalent in pg_bitutils.h
- b1187266e077 19 (unreleased) landed
-
Change dynahash.c and hsearch.h to use int64 instead of long
- 13b935cd5217 19 (unreleased) landed