remove bits* types

On 2026-Mar-18, Nathan Bossart wrote:

Well, in the process of seeing how bad the patch would look, I ended up
writing it. I used sed for most of this, and I tried to make all necessary
manual adjustments, but I may have missed a couple.

Shrug. As I said in the other thread, it seems mildly useful to
distinguish the cases where stuff is there solely to be treated as a
mask of independent bits instead of something you do arithmetic with.
But if nobody else likes this, I won't stand in your way.

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"No tengo por qué estar de acuerdo con lo que pienso"
(Carlos Caszeli)

=?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de> writes:

Shrug. As I said in the other thread, it seems mildly useful to
distinguish the cases where stuff is there solely to be treated as a
mask of independent bits instead of something you do arithmetic with.

I could get behind that if we were declaring bitmask variables using
bitsNN more or less consistently, but if we do that at all it's a
minority usage. I didn't even realize there was any such convention.
A lot of the places Nathan is changing don't look like they are
following such a convention anyway.

In short: maybe we don't want to go in the direction Nathan suggests,
but if we keep these types we should make an effort to use them
more consistently, so there's work to be done in that direction too.

regards, tom lane

On Wed, Mar 18, 2026 at 6:41 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

In short: maybe we don't want to go in the direction Nathan suggests,
but if we keep these types we should make an effort to use them
more consistently, so there's work to be done in that direction too.

I'm definitely -1 on trying to use them more consistently. This is a
261 line patch. The reverse patch to use these types everywhere that
we use integers as a collection of bits is probably 100 times that
size. If you took that idea to its logical conclusion, every flags
variable in the backend would end up getting converted.

I'm not entirely sure that this is worth standardizing at all; if
someone thinks that using bits8 or whatever makes the code more rather
than less clear in a certain context, who am I to argue? If someone
else prefers uint8 in another context, also fine.

But if we are going to standardize, I think the only sensible choice
is what Nathan's done here. The reverse would be an insane amount of
code churn.

--
Robert Haas
EDB: http://www.enterprisedb.com

On 2026-Mar-18, Robert Haas wrote:

I'm not entirely sure that this is worth standardizing at all; if
someone thinks that using bits8 or whatever makes the code more rather
than less clear in a certain context, who am I to argue? If someone
else prefers uint8 in another context, also fine.

I don't think we _have_ to force our hand one way or the other.

--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"It takes less than 2 seconds to get to 78% complete; that's a good sign.
A few seconds later it's at 90%, but it seems to have stuck there. Did
somebody make percentages logarithmic while I wasn't looking?"
http://smylers.hates-software.com/2005/09/08/1995c749.html

On Wed, Mar 18, 2026 at 07:15:29PM -0400, Robert Haas wrote:

I'm definitely -1 on trying to use them more consistently. This is a
261 line patch. The reverse patch to use these types everywhere that
we use integers as a collection of bits is probably 100 times that
size. If you took that idea to its logical conclusion, every flags
variable in the backend would end up getting converted.

This is definitely not accurate, but I counted around 400 such cases for
the reverse patch:

$ grep -E "int[0-9]* (flags|options)" src/* -rI | wc -l
409

I'm not entirely sure that this is worth standardizing at all; if
someone thinks that using bits8 or whatever makes the code more rather
than less clear in a certain context, who am I to argue? If someone
else prefers uint8 in another context, also fine.

But if we are going to standardize, I think the only sensible choice
is what Nathan's done here. The reverse would be an insane amount of
code churn.

While nobody seems totally opposed to the idea, it does seem to be
generating some discussion. I'd rather not distract more important work
for v19, so I'm happy to put it on the shelf for now.

--
nathan

=?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de> writes:

On 2026-Mar-18, Robert Haas wrote:

I'm not entirely sure that this is worth standardizing at all; if
someone thinks that using bits8 or whatever makes the code more rather
than less clear in a certain context, who am I to argue? If someone
else prefers uint8 in another context, also fine.

I don't think we _have_ to force our hand one way or the other.

I'm content with the status quo personally, but perhaps it'd be
worth adding some info to the comment for the bitsNN typedefs
to make it clearer what they are intended for. I'm imagining
something along the lines of

 /*
  * bitsN
  *		Unit of bitwise operation, AT LEAST N BITS IN SIZE.
+ *
+ * Use these type names for values that are intended to be manipulated
+ * as sets of bits, for example bitmasks of flags, null bitmaps, etc.
+ * If it'd be sensible to do arithmetic on it, it's not a set of bits.
  */
 typedef uint8 bits8;			/* >= 8 bits */
 typedef uint16 bits16;			/* >= 16 bits */
 typedef uint32 bits32;			/* >= 32 bits */

regards, tom lane

On Thu, Mar 19, 2026 at 12:22:10PM -0400, Tom Lane wrote:

I'm content with the status quo personally, but perhaps it'd be
worth adding some info to the comment for the bitsNN typedefs
to make it clearer what they are intended for. I'm imagining
something along the lines of

Not sure why we absolutely need to be aggressive with a removal here,
so I'm +/-0 on that. And there is always the argument of breaking the
compilation of out-of-core code. That would be easily fixable, still
always slightly annoying.
--
Michael

On 18.03.26 22:38, Nathan Bossart wrote:

(new thread)

On Wed, Mar 18, 2026 at 04:17:40PM -0500, Nathan Bossart wrote:

On Tue, Mar 17, 2026 at 05:09:49PM -0400, Andres Freund wrote:

Personally I object to the existence of the bits* types, to me they're just
noise over using the corresponding unsigned integer types. One more thing that
one has to just know what it means without there being any actual improved
type checking or such. It's not like using bits* would make it any easier to
make the underlying type a struct or such (which is different to
e.g. TransactionId, we could probably replace that with a struct without crazy
amounts of trouble).

Yeah, I don't see why you'd prefer bits32 over uint32. If anything, uint32
is probably less confusing because most hackers will have used it before.
AFAICT the bits* types are a relic of the 80s, and there used to be other
types like bool8 and word32, all of which were just uint* behind the
scenes. Those were removed in 2004 by commit ca7a1f0c86. I assume bits*
was left behind because it was still in use.

I think we should just rip the bits* types out and replace them with the
underlying types.

+1. If there seems to be consensus, I'm happy to write the patch.

Well, in the process of seeing how bad the patch would look, I ended up
writing it. I used sed for most of this, and I tried to make all necessary
manual adjustments, but I may have missed a couple.

I'm mildly in favor of removing them. But it appears there is no consensus.

On Wed, Mar 25, 2026 at 05:27:34PM +0100, Peter Eisentraut wrote:

I'm mildly in favor of removing them. But it appears there is no consensus.

Same here. While it still doesn't look like anybody is totally opposed to
the idea, you are right that there is no consensus.

--
nathan

On Thu, Mar 26, 2026 at 2:21 PM Nathan Bossart <nathandbossart@gmail.com> wrote:

On Wed, Mar 25, 2026 at 05:27:34PM +0100, Peter Eisentraut wrote:

I'm mildly in favor of removing them. But it appears there is no consensus.

Same here. While it still doesn't look like anybody is totally opposed to
the idea, you are right that there is no consensus.

I really wish we would remove them. I want fewer confusing typedefs in
the code -- not more. I'm quite sad that as of 1bd6f22f43ac1b we are
now using them more widely (and publicly), and I feel that was done
without consensus. It should just use a regular uint32 -- like other
places we do this (e.g. scan_begin() amongst many others).

- Melanie

On Mon, Mar 30, 2026 at 12:41:09PM -0400, Melanie Plageman wrote:

On Thu, Mar 26, 2026 at 2:21 PM Nathan Bossart <nathandbossart@gmail.com> wrote:

On Wed, Mar 25, 2026 at 05:27:34PM +0100, Peter Eisentraut wrote:

I'm mildly in favor of removing them. But it appears there is no consensus.

Same here. While it still doesn't look like anybody is totally opposed to
the idea, you are right that there is no consensus.

I really wish we would remove them. I want fewer confusing typedefs in
the code -- not more. I'm quite sad that as of 1bd6f22f43ac1b we are
now using them more widely (and publicly), and I feel that was done
without consensus. It should just use a regular uint32 -- like other
places we do this (e.g. scan_begin() amongst many others).

Thanks for the heads-up. Here's a rebased patch.

With Melanie's note, there are at least 4 votes in favor of this patch
(Andres, me, Peter, and Melanie). AFAICT Michael is +/-0, Álvaro and Tom
are -1 (or somewhere in the vicinity), and Robert seems ambivalent. Hm...

--
nathan

Nathan Bossart <nathandbossart@gmail.com> writes:

With Melanie's note, there are at least 4 votes in favor of this patch
(Andres, me, Peter, and Melanie). AFAICT Michael is +/-0, Álvaro and Tom
are -1 (or somewhere in the vicinity), and Robert seems ambivalent. Hm...

To clarify, what I said was we should either remove them or use them
more consistently. I don't think 1bd6f22f4 moved the needle very
far towards option 2, so I'm totally fine with option 1. Put me
down as +0.5.

regards, tom lane

On Mon, Mar 30, 2026 at 01:07:32PM -0400, Tom Lane wrote:

Nathan Bossart <nathandbossart@gmail.com> writes:

With Melanie's note, there are at least 4 votes in favor of this patch
(Andres, me, Peter, and Melanie). AFAICT Michael is +/-0, Álvaro and Tom
are -1 (or somewhere in the vicinity), and Robert seems ambivalent. Hm...

To clarify, what I said was we should either remove them or use them
more consistently. I don't think 1bd6f22f4 moved the needle very
far towards option 2, so I'm totally fine with option 1. Put me
down as +0.5.

Thanks for clarifying. Given that update and Álvaro's note upthread [0]/messages/by-id/202603182215.rvi6x75ekyba@alvherre.pgsql,
I'd argue we're in rough consensus territory and can move forward with the
patch. If no objections materialize shortly, I'll do so.

[0]: /messages/by-id/202603182215.rvi6x75ekyba@alvherre.pgsql

--
nathan

Nathan Bossart <nathandbossart@gmail.com> writes:

On Mon, Mar 30, 2026 at 01:07:32PM -0400, Tom Lane wrote:

Nathan Bossart <nathandbossart@gmail.com> writes:

With Melanie's note, there are at least 4 votes in favor of this patch
(Andres, me, Peter, and Melanie). AFAICT Michael is +/-0, Álvaro and Tom
are -1 (or somewhere in the vicinity), and Robert seems ambivalent. Hm...

To clarify, what I said was we should either remove them or use them
more consistently. I don't think 1bd6f22f4 moved the needle very
far towards option 2, so I'm totally fine with option 1. Put me
down as +0.5.

Thanks for clarifying. Given that update and Álvaro's note upthread [0],
I'd argue we're in rough consensus territory and can move forward with the
patch. If no objections materialize shortly, I'll do so.

To avoid breaking extensions, we could leave the typedefs in place with
an #ifndef guard on some symbol that's only defined when building
postgres itself, but not when building extensions (or vice versa with an
#ifdef instead).

This is used a lot in Perl for things we don't want to use in core any
more, but we don't want to break CPAN modules still using.

- ilmari

On Mon, Mar 30, 2026 at 06:36:48PM +0100, Dagfinn Ilmari Mannsåker wrote:

To avoid breaking extensions, we could leave the typedefs in place with
an #ifndef guard on some symbol that's only defined when building
postgres itself, but not when building extensions (or vice versa with an
#ifdef instead).

This is used a lot in Perl for things we don't want to use in core any
more, but we don't want to break CPAN modules still using.

It's hard to get an exact count because the names are so common, but I'm
seeing <10 packages on codesearch.debian.net that might be affected, and
it's quite easy to fix (s/bits/uint/g). My experience is that we routinely
"break" extensions like this in new major versions, too. So, I'm not
convinced we need to do any kind of backward-compatibility work. In any
case, we have a lot of time between now and GA, so if a bunch of angry
extension authors come to my door with pitchforks, we can reconsider.

--
nathan

Nathan Bossart <nathandbossart@gmail.com> writes:

It's hard to get an exact count because the names are so common, but I'm
seeing <10 packages on codesearch.debian.net that might be affected, and
it's quite easy to fix (s/bits/uint/g). My experience is that we routinely
"break" extensions like this in new major versions, too. So, I'm not
convinced we need to do any kind of backward-compatibility work. In any
case, we have a lot of time between now and GA, so if a bunch of angry
extension authors come to my door with pitchforks, we can reconsider.

Agreed. As incompatible changes go, this is pretty darn minor
and easy to deal with.

regards, tom lane

Committed.

--
nathan