Re: Remove traces of long in dynahash.c - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Remove traces of long in dynahash.c
Date
Msg-id 1371795.1755751989@sss.pgh.pa.us
Whole thread Raw
In response to Re: Remove traces of long in dynahash.c  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Remove traces of long in dynahash.c
List pgsql-hackers
Michael Paquier <michael@paquier.xyz> writes:
> On Wed, Aug 20, 2025 at 04:14:15PM +0800, Chao Li wrote:
>> I wonder if we can keep the same naming style to make the new
>> function name like next_pow2_64()?

> I don't think that this would be a good idea to have new routines
> published in pg_bitutils.h with names inconsistent with the existing
> one.  next_pow2_long() and next_pow2_int() are now local to
> dynahash.c, so we don't really have to follow their naming pattern.
> It would be more important to me to choose a new name, rather in line
> with the other ones.

Yes, the precedent to follow here is the naming conventions in
pg_bitutils.h.

> After sleeping on it, I am not sure what to do with these routines.  I
> don't deny that more refactoring can be done.  However, all that can
> also happen outside the long -> int64 switch I am suggesting.

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.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Possible inaccurate description of wal_compression in docs
Next
From: Alexandra Wang
Date:
Subject: Re: SQL:2023 JSON simplified accessor support