From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Remove traces of long in dynahash.c |
Date: | 2025-08-21 04:53:09 |
Message-ID: | 1371795.1755751989@sss.pgh.pa.us |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michael Paquier <michael(at)paquier(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alexandra Wang | 2025-08-21 04:53:53 | Re: SQL:2023 JSON simplified accessor support |
Previous Message | Michael Paquier | 2025-08-21 04:28:28 | Re: Possible inaccurate description of wal_compression in docs |