Re: move some bitmapset.c macros to bitmapset.h

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: move some bitmapset.c macros to bitmapset.h
Дата
Msg-id 3548001.1670302640@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: move some bitmapset.c macros to bitmapset.h  (John Naylor <john.naylor@enterprisedb.com>)
Ответы Re: move some bitmapset.c macros to bitmapset.h  (David Rowley <dgrowleyml@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: Re: ANY_VALUE aggregate
Следующее
От: "Drouvot, Bertrand"
Дата:
Сообщение: Re: Generate pg_stat_get_* functions with Macros