Re: Remove traces of long in dynahash.c
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Chao Li <li.evan.chao@gmail.com>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-08-22T05:09:51Z
Lists: pgsql-hackers
Attachments
- 0001-Clean-up-next-pow2-routines-of-dynahash.c-moving-to-.patch (text/x-diff) patch 0001
On Thu, Aug 21, 2025 at 12:53:09AM -0400, Tom Lane wrote: > If you prefer to regard this as an independent issue, that's okay with > me ... but it's touching most of the same lines of code, so it seems > to me that it'd be about as easy to deal with both items at once. I'd rather do that after a second look at the whole picture as this led to an accumulation of bullet points. The long->int64 switch was looking OK on its own and I have applied it. Attached is the second piece of refactoring, where I have introduced a couple more APIs in pg_bitutils.h (cross-checked the resulting computations of the old and new routines with some quick hacks, in case, and they matched): pg_nextpower2_32_bound, replacing next_pow2_int pg_nextpower2_64_bound, replacing next_pow2_int64 pg_ceil_log2_64_bound, replacing my_log2() pg_ceil_log2_32_bound, not used, present for symmetry. An extra thing is a suggested change for pg_nextpower2_32(), to use a uint64 instead of a uint32 as argument, which is caused by next_pow2_int64() and next_pow2_int(), that both used int64 previously. There's likely some opinion differences according to one's taste; that's my idea of the refactoring to remove the duplication. -- 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