Change definitions of bitmap flags to bit-shifting style
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t43357psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 27, 2026 at 06:02 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t43357_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t43357_1 && git checkout t43357_1Patchset v1 (message #1) is on t43357_1
The attached patch changes definitions like
#define FOO 0x01
#define BAR 0x02
to
#define FOO (1 << 0)
#define BAR (1 << 1)
etc.
Both styles are currently in use, but the latter style seems more
readable and easier to update.
This change only addresses bitmaps used in memory (e.g., for parsing or
specific function APIs), where the actual bits don't really matter.
Bits that might go on disk weren't touched. There, defining the bits in
a more concrete way seems better.
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
The attached patch changes definitions like
#define FOO 0x01
#define BAR 0x02
to
#define FOO (1 << 0)
#define BAR (1 << 1)
etc.
Both styles are currently in use, but the latter style seems more
readable and easier to update.
FWIW, personally I'd vote for doing the exact opposite. When you are
debugging and examining the contents of a bitmask variable, it's easier to
correlate a value like "0x03" with definitions made in the former style.
Or at least I think so; maybe others see it differently.
regards, tom lane
On 2020-Dec-05, Tom Lane wrote:
FWIW, personally I'd vote for doing the exact opposite. When you are
debugging and examining the contents of a bitmask variable, it's easier to
correlate a value like "0x03" with definitions made in the former style.
Or at least I think so; maybe others see it differently.
The hexadecimal representation is more natural to me than bit-shifting,
so I would prefer to use that style too. But maybe I'm trained to it
because of looking at t_infomask symbols constantly.
On Sat, 2020-12-05 at 13:03 -0500, Tom Lane wrote:
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
The attached patch changes definitions like
#define FOO 0x01
#define BAR 0x02
to
#define FOO (1 << 0)
#define BAR (1 << 1)
etc.Both styles are currently in use, but the latter style seems more
readable and easier to update.FWIW, personally I'd vote for doing the exact opposite. When you are
debugging and examining the contents of a bitmask variable, it's easier to
correlate a value like "0x03" with definitions made in the former style.
Or at least I think so; maybe others see it differently.
+1
Laurenz Albe
On Sat, Dec 05, 2020 at 10:31:09PM -0300, Alvaro Herrera wrote:
The hexadecimal representation is more natural to me than bit-shifting,
so I would prefer to use that style too. But maybe I'm trained to it
because of looking at t_infomask symbols constantly.
If we are going to change all that, hexa style sounds good to me too.
Would it be worth an addition to the docs, say in [1]https://www.postgresql.org/docs/devel/source-conventions.html? -- Michael to tell that
this is a preferred style?
[1]: https://www.postgresql.org/docs/devel/source-conventions.html? -- Michael
--
Michael
On Sun, Dec 6, 2020 at 1:25 AM Michael Paquier <michael@paquier.xyz> wrote:
On Sat, Dec 05, 2020 at 10:31:09PM -0300, Alvaro Herrera wrote:
The hexadecimal representation is more natural to me than bit-shifting,
so I would prefer to use that style too. But maybe I'm trained to it
because of looking at t_infomask symbols constantly.If we are going to change all that, hexa style sounds good to me too.
Would it be worth an addition to the docs, say in [1] to tell that
this is a preferred style?[1]: https://www.postgresql.org/docs/devel/source-conventions.html?
--
Michael
In my view the bit shifting approach makes it more obvious a single bit is
being set, but on the other hand the hex approach makes it easier to
compare in debugging.
I’m not really sure which to prefer, though I think I would have leaned
slightly towards the former.
James
Show quoted text
On 12/6/20 11:44 AM, James Coleman wrote:
On Sun, Dec 6, 2020 at 1:25 AM Michael Paquier <michael@paquier.xyz
<mailto:michael@paquier.xyz>> wrote:On Sat, Dec 05, 2020 at 10:31:09PM -0300, Alvaro Herrera wrote:
The hexadecimal representation is more natural to me than
bit-shifting,
so I would prefer to use that style too. But maybe I'm trained
to it
because of looking at t_infomask symbols constantly.
If we are going to change all that, hexa style sounds good to me too.
Would it be worth an addition to the docs, say in [1] to tell that
this is a preferred style?[1]: https://www.postgresql.org/docs/devel/source-conventions.html
<https://www.postgresql.org/docs/devel/source-conventions.html>?
--
MichaelIn my view the bit shifting approach makes it more obvious a single
bit is being set, but on the other hand the hex approach makes it
easier to compare in debugging.I’m not really sure which to prefer, though I think I would have
leaned slightly towards the former.
Perhaps we should put one style or the other in a comment. I take Tom's
point, but after the number of bits shifted gets above some number I
have trouble remembering which bit it is, and while of course I can work
it out, it can be a very minor nuisance.
cheers
andrew