PostgreSQL 15 不支持 BIT_AND 函数，因其设计上未提供位与聚合函数，官方认为语义易误用且场景较少；推荐用自定义聚合函数（如基于 int4and 或 PL/pgSQL 实现）或补码技巧（~int4or(~x)）替代，需严格处理 NULL、负数及位宽问题。
PostgreSQL 15 不支持 BIT_AND 函数，直接调用会报错 function bit_and(integer) does not exist。 它没有 MySQL 那样的原生位聚合函数，哪怕你升级到 15，这个函数依然不存在 —— 不是 bug，是设计如此。
为什么 PostgreSQL 没有 BIT_AND 和 BIT_OR
PostgreSQL 的位聚合能力被拆解为更底层、更可控的机制：它提供 int4or() / int8or()（用于 OR），但始终没加 int4and() 这类 AND 聚合函数。官方认为位与交集（AND）语义容易被误用（比如忽略 NULL 导致整组结果为 NULL），且多数真实场景中“全员都开启某权限”这类需求本身较少，不如在应用层处理更清晰。
常见错误现象：
- 写
SELECT BIT_AND(status_mask) FROM events GROUP BY group_id→ 报错function bit_and(integer) does not exist - 试图用
bit_and(status_mask::bit(32))→ 报错function bit_and(bit) does not exist（bit_and()只接受bit(n)类型，但 PostgreSQL 15 中该函数仍不支持整数转 bit 后的聚合，且行为不可靠）
PostgreSQL 15 中替代 BIT_AND 的可靠方案
必须明确：你要的是「某组内所有非 NULL 行在每一位上是否全为 1」——这等价于「该组所有值的按位与结果」。PostgreSQL 没有内置聚合函数，但可以用窗口 + 递归或聚合框架模拟。生产环境推荐以下两种方式：
- 用
int4or()配合补码思路反推（仅适用于已知掩码位宽且无负数）：先算出全集掩码（如0xFFFFFFFF），再用~int4or(~status_mask)，但需确保status_mask全为非负、且位宽一致，否则翻车 - 最稳妥的是用
array_agg()+ 自定义聚合函数（推荐）：CREATE AGGREGATE bit_and_agg(integer) ( SFUNC = int4and, STYPE = integer, INITCOND = '2147483647' -- 0x7FFFFFFF，即 31 个 1（注意符号位） );
但注意：int4and是内部函数，未公开文档，部分 PG 15 小版本可能不可用；更可移植的做法是用 PL/pgSQL 写一个安全聚合函数，显式跳过 NULL，并从初始值（如-1或0xFFFFFFFF）开始逐行& - 简单场景（组内行数少、性能不敏感）：用
ARRAY+unnest+ 窗口函数模拟，例如：SELECT group_id, (SELECT BIT_AND(x) FROM unnest(arr) AS x) AS common_bits FROM (SELECT group_id, ARRAY_AGG(status_mask) AS arr FROM events GROUP BY group_id) t;但注意：这里BIT_AND(x)仍是非法的，实际要改用子查询中循环计算，所以不实用
别踩坑：NULL、负数和位宽陷阱
即使你绕过了函数缺失问题，下面这些细节照样让结果错得离谱：
-
status_mask字段含NULL？默认聚合会跳过，但如果你用自定义聚合没处理，结果可能意外为NULL—— 必须提前COALESCE(status_mask, 0)或WHERE status_mask IS NOT NULL - 字段是
integer（32 位），但业务用了第 32 位（即0x80000000）？那它会被解释为负数，&运算在符号扩展下行为异常；建议统一用bigint+int8and（若可用），或限定掩码只用低 31 位 - 想查“所有设备都上报了在线状态（bit 0）”，别写
(bit_and_result & 1) = 1—— 如果聚合结果因某行为 NULL 而整体为 NULL，整个表达式就失效；应先判断聚合结果是否非 NULL
真正上线前，务必用包含 NULL、0、全 1、负值的测试数据跑一遍聚合逻辑 —— PostgreSQL 的位运算不报错，但结果沉默地错了。
