Re: move some bitmapset.c macros to bitmapset.h
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: John Naylor <john.naylor@enterprisedb.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-12-06T04:57:20Z
Lists: 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
Commits
-
Move some bitmap logic out of bitmapset.c
- 3e76a806cbb0 17.0 landed