PostgreSQL本身无BIT_COUNT函数，因设计哲学倾向组合功能而非内置专用函数；13+版本可用原生popcount()，旧版需手动位运算或generate_series模拟，且须确保掩码值为2的幂以保证语义正确。
PostgreSQL 本身没有 BIT_COUNT 函数，直接调用会报错 function bit_count(integer) does not exist。你需要用等效的、PostgreSQL 原生支持的方式实现位计数（即统计整数二进制表示中 1 的个数）。
为什么 PostgreSQL 没有 BIT_COUNT？
MySQL 和 MariaDB 提供了 BIT_COUNT()，但 PostgreSQL 的设计哲学更倾向组合已有功能而非内置专用函数。它提供了底层位操作（如 &、>>、popcount 扩展），但核心函数库不包含开箱即用的 BIT_COUNT。
常见错误现象：在 pgAdmin 或 psql 中执行 SELECT BIT_COUNT(5);，立刻返回函数不存在错误。
- PostgreSQL 13+ 用户可直接使用内置
popcount()（仅限integer和bigint） - 旧版本需手动实现或启用
intarray扩展（不推荐，它不提供 popcount） - 别试图用
bit_length(x::bit(n)) - length(replace(x::bit(n)::text, '0', ''))—— 效率极低且对负数行为异常
PostgreSQL 13+ 推荐方案：用 popcount() 函数
popcount() 是 PostgreSQL 13 引入的原生函数，语义和性能完全对标其他数据库的 BIT_COUNT，支持 integer 和 bigint 类型。
使用场景：统计权限掩码、特征向量、状态位字段中启用的标志数量。
SELECT id, flags, popcount(flags) AS active_flags FROM permissions WHERE popcount(flags) >= 3;
- 参数必须是整数类型；传入
text或numeric会报错function popcount(text) does not exist - 对负数按二进制补码解释（例如
popcount(-1::integer)返回 32 或 64，取决于平台字长） - 性能接近 C 级别内置指令，远快于字符串拆解方案
兼容旧版本 PostgreSQL（
若无法升级，可用递归位移 + 模运算模拟 popcount，但务必限制输入范围避免栈溢出或性能崩坏。
推荐内联写法（无需创建函数），适用于中小数据集：
SELECT x, (x & 1) + ((x >> 1) & 1) + ((x >> 2) & 1) + ((x >> 3) & 1) + ((x >> 4) & 1) + ((x >> 5) & 1) + ((x >> 6) & 1) + ((x >> 7) & 1) AS bits_8 FROM (VALUES (5), (15), (255)) t(x);
- 此例只覆盖低 8 位；扩展到 32 位需写满 32 项，可读性与维护性急剧下降
- 更通用的做法是用
generate_series配合位检测，但会显著拖慢查询 —— 千行以内可接受，万行以上慎用 - 绝对不要在 WHERE 条件里对大表列调用复杂表达式，会导致全表扫描且无法走索引
位掩码统计的实际陷阱
真正容易被忽略的不是函数怎么写，而是位掩码本身的语义一致性。
比如你用 flags 存储用户权限：1 = read, 2 = write, 4 = delete，那么 popcount(flags) 确实等于启用权限数。但一旦业务混入非幂等位（如用 3 表示“只读+审计”复合状态），popcount 就失去业务意义。
- 确保所有掩码值都是 2 的幂（
1, 2, 4, 8, ...），否则统计结果不可解释 - 检查数据库约束：建议加 CHECK 约束，例如
CHECK (flags & (flags - 1) = 0 OR flags = 0)（验证是否为 2 的幂或零） - 注意符号位：
smallint最高位是符号位，popcount(-128::smallint)返回 1，不是 8
用错类型或忽略位定义规则，比不会写 popcount 更容易导致线上统计偏差。
