Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w2zbB-000nPe-1s for pgsql-hackers@arkaria.postgresql.org; Wed, 18 Mar 2026 22:42:45 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w2zbA-00F4No-1V for pgsql-hackers@arkaria.postgresql.org; Wed, 18 Mar 2026 22:42:44 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w2zZu-00EzX1-0E for pgsql-hackers@lists.postgresql.org; Wed, 18 Mar 2026 22:41:26 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1w2zZq-00000000RE8-3TtH for pgsql-hackers@lists.postgresql.org; Wed, 18 Mar 2026 22:41:25 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 62IMfKjm1074367; Wed, 18 Mar 2026 18:41:21 -0400 From: Tom Lane To: =?utf-8?Q?=C3=81lvaro?= Herrera cc: Nathan Bossart , Andres Freund , Pg Hackers Subject: Re: remove bits* types In-reply-to: <202603182215.rvi6x75ekyba@alvherre.pgsql> References: <202603182215.rvi6x75ekyba@alvherre.pgsql> Comments: In-reply-to =?utf-8?Q?=C3=81lvaro?= Herrera message dated "Wed, 18 Mar 2026 23:18:06 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1074365.1773873680.1@sss.pgh.pa.us> Date: Wed, 18 Mar 2026 18:41:20 -0400 Message-ID: <1074366.1773873680@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk =?utf-8?Q?=C3=81lvaro?= Herrera 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