On 01.09.25 05:25, Michael Paquier wrote:
So, taking a step back, I don't know what would be a good fit for
these duplicates of the "next power" routines upper-bounded on input
when attached to pg_bitutils.h. However, I do see that we can get rid
of pg_log2() and dynahash.h with a consistent int
On Wed, Aug 27, 2025 at 10:00:16AM +0200, Peter Eisentraut wrote:
> That seems highly confusing. What is the meaning of the "32" then?
>
> If you need 64-bit behavior, use the variant with "64" in the name.
static int
next_pow2_int(int64 num)
{
if (num > INT_MAX / 2)
num = INT_MAX /
On 22.08.25 07:09, Michael Paquier wrote:
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.
That seems highly confusing. What is the meaning of
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 s
Michael Paquier 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 inc
Hi Michael,
> On Aug 21, 2025, at 07:07, Michael Paquier wrote:
>
>
> 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.
>
> Any comments f
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.
> On Aug 20, 2025, at 15:40, Michael Paquier wrote:
>
> On Tue, Aug 19, 2025 at 10:46:58AM -0400, Tom Lane wrote:
>> +1 for getting rid of those while we're doing janitorial work here.
>> They're not *quite* duplicates though, for instance next_pow2_int has
>> different response to out-of-range
On Tue, Aug 19, 2025 at 10:46:58AM -0400, Tom Lane wrote:
> +1 for getting rid of those while we're doing janitorial work here.
> They're not *quite* duplicates though, for instance next_pow2_int has
> different response to out-of-range values than pg_nextpower2_32.
This would mean introducing mor
On 19.08.25 08:24, Michael Paquier wrote:
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.
It's definitely a good idea to get rid of "long" usage. But you can
also replace it with long long instead of int64. I
Chao Li writes:
>> On Aug 19, 2025, at 14:24, Michael Paquier wrote:
>> <0001-Replace-uses-of-long-by-uint64-in-dynahash.c-and-hse.patch>
> There are already pg_nextpower2_64() and pg_nextpower2_32() in pg_bitutils.h,
> feels like the new replacement functions are duplicate to the existing ones
> On Aug 19, 2025, at 14:24, Michael Paquier wrote:
>
>
> --
> Michael
> <0001-Replace-uses-of-long-by-uint64-in-dynahash.c-and-hse.patch>
-static long next_pow2_long(long num);
-static int next_pow2_int(long num);
+static uint64 next_pow2_uint64(uint64 num);
+static int next_pow2_i
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 everywhe
13 matches
Mail list logo
