Subject: remove bits* types

From: Nathan Bossart <[email-masked]>
Date: Wed, 18 Mar 2026 16:38:39 -0500

(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.

-- 
nathan

---

From: Peter Eisentraut <[email-masked]>
Date: Wed, 25 Mar 2026 17:27:34 +0100

> manual adjustments, but I may have missed a couple.

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

---

From: Nathan Bossart <[email-masked]>
Date: Thu, 26 Mar 2026 13:21:41 -0500

> 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

---

From: Melanie Plageman <[email-masked]>
Date: Mon, 30 Mar 2026 12:41:09 -0400

> 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

---

From: Nathan Bossart <[email-masked]>
Date: Mon, 30 Mar 2026 12:00:01 -0500

> 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

---

From: Nathan Bossart <[email-masked]>
Date: Mon, 30 Mar 2026 12:12:13 -0500

On Mon, Mar 30, 2026 at 01:07:32PM -0400, Tom Lane wrote:
> Nathan Bossart <[email-masked]> writes:
> 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.

[0] https://postgr.es/m/202603182215.rvi6x75ekyba%40alvherre.pgsql

-- 
nathan

---

From: Dagfinn Ilmari Mannsåker <[email-masked]>
Date: Mon, 30 Mar 2026 18:36:48 +0100

> 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

---

From: Nathan Bossart <[email-masked]>
Date: Mon, 30 Mar 2026 13:00:07 -0500

> 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

---

From: Nathan Bossart <[email-masked]>
Date: Mon, 30 Mar 2026 16:13:32 -0500

Committed.

-- 
nathan