PostgreSQL中应使用int8or()替代BIT_OR(integer)，因其原生支持整数位或聚合且行为与MySQL一致；需显式转换类型并用COALESCE处理NULL，权限校验须在聚合后用&操作符配合括号确保优先级。
PostgreSQL 里没有 BIT_OR(integer) 这个函数
直接写 BIT_OR(col) 会报错：function bit_or(integer) does not exist。PostgreSQL 的 bit_or() 只接受 bit(n) 类型，不接受整数。这不是语法写错，是类型系统强制要求——你传 INT，它真不认识。
用 int8or() 替代 BIT_OR 是最稳妥的方案
PostgreSQL 自带聚合函数 int8or()（对应 64 位整数），无需安装扩展，通常默认可用。它行为和 MySQL 的 BIT_OR 一致：对非 NULL 整数值逐位或，返回 INT8 结果。
- 确保字段是整型（
SMALLINT/INTEGER/BIGINT），别是TEXT或ENUM，否则静默转 0 - 如果权限值存的是
SMALLINT，调用时显式转成BIGINT更安全：int8or(perm_flag::BIGINT) - 空组返回
NULL，生产环境必须用COALESCE(int8or(perm_flag), 0)防止后续&判断失效
非要硬用 bit_or()？得先 CAST 再聚合
如果你坚持走 bit_or() 路线（比如已有 bit 字段），必须显式转类型：
-
bit_or(perm_flag::bit(64))—— 长度选小了会截断，比如bit(8)存不下 256（需要至少 9 位） - 不能写
bit_or(CAST(perm_flag AS bit))，因为没指定长度，PostgreSQL 会报错 - 转完后结果是
bit(64)，后续做权限校验还得转回整数：('101'::bit(64))::bigint，多此一举
权限校验千万别在聚合层做
int8or() 或 bit_or() 只负责合并掩码，不是判断工具。查“用户是否有导出权限（bit 3 = 8）”必须写成：
SELECT (int8or(perm_flag) & 8) != 0 AS has_export FROM ... GROUP BY user_id
- 括号不能省：
&优先级低于!=，int8or(perm_flag) & 8 != 0会被解析为int8or(perm_flag) & (8 != 0)，即int8or(perm_flag) & 1，结果全错 - 单行权限检查永远用
&，不是int8or()；聚合函数只出现在SELECT或HAVING，绝不在WHERE里直接调用 - 如果权限来源跨多张表（比如角色+用户+租户），GROUP BY 维度漏掉租户 ID，会导致权限污染——这是线上事故高发点
