Re: move some bitmapset.c macros to bitmapset.h - Mailing list pgsql-hackers

From Tom Lane
Subject Re: move some bitmapset.c macros to bitmapset.h
Date
Msg-id 3548001.1670302640@sss.pgh.pa.us
Whole thread Raw
In response to Re: move some bitmapset.c macros to bitmapset.h  (John Naylor <john.naylor@enterprisedb.com>)
Responses Re: move some bitmapset.c macros to bitmapset.h  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers
John Naylor <john.naylor@enterprisedb.com> writes:
> On Mon, Dec 5, 2022 at 9:33 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> IMV these are absolutely private to bitmapset.c.  I reject the idea
>> that they should be exposed publicly, under these names or any others.

> Well, they've already escaped to tidbitmap.c as a copy. How do you feel
> about going that route?

Not terribly pleased with that either, I must admit.

>> Maybe we need some more bitmapset primitive functions?  What is it
>> you actually want to accomplish in the end?

>     for (idx = 0; idx < WORDNUM(128); idx++)

BITS_PER_BITMAPWORD is already public, so can't you spell that

    for (idx = 0; idx < 128/BITS_PER_BITMAPWORD; idx++)

> slotpos += bmw_rightmost_one_pos(inverse);

I'm not terribly against exposing bmw_rightmost_one_pos, given
that it's just exposing the pg_rightmost_one_posXX variant that
matches BITS_PER_BITMAPWORD.

> isset[idx] |= RIGHTMOST_ONE(inverse);

And RIGHTMOST_ONE is something that could be made public, but
I think it belongs in pg_bitutils.h, perhaps with a different
name.

> ...which, if it were reversed so that a set bit meant "available", would
> essentially be bms_first_member(), so a more primitive version of that
> might work.

That could be a reasonable direction to pursue as well.

            regards, tom lane



pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: ANY_VALUE aggregate
Next
From: "Drouvot, Bertrand"
Date:
Subject: Re: Generate pg_stat_get_* functions with Macros