postgresql和瀚高数据库中boolean列不接受0/1作为默认值或where条件值，因二者无隐式转换规则；必须显式使用default false/true或where is_active = true。
PostgreSQL 和瀚高数据库里，boolean 列不能直接接受 0/1 作为默认值或 WHERE 条件值；MySQL 虽然允许，但会破坏索引、返回意外结果；SQL Server 在布尔比较中不原生支持 boolean 类型，容易触发隐式转换导致性能下降。根本解法不是绕开类型检查，而是让应用层和 SQL 层的类型表达完全对齐。
PostgreSQL 建表时 DEFAULT 0 报错：column "x" is of type boolean but default expression is of type integer
这是 DDL 阶段的硬性拦截，不是运行时报错。PostgreSQL 在解析 DEFAULT 0 时，把整数字面量 0 推导为 integer 类型，而列定义是 boolean，两者之间没有注册隐式转换规则（pg_cast 中查不到 integer → boolean 的 castcontext = 'i' 记录）。
- 修复写法必须显式转成布尔字面量：
DEFAULT false或DEFAULT true，不能用0/1 - 如果参数来自应用层（如 Java 的
int字段），DAO 层需先做逻辑映射：is_active ? "true" : "false"，再拼入 SQL；用#{isActive}时确保传的是Boolean类型，而非Integer或String - 临时兼容方案（不推荐）：在
pg_cast中手动插入一条转换规则，但会影响所有 boolean 比较行为，且升级后可能被清空
WHERE 条件里写 WHERE is_active = 1 导致索引失效
哪怕表已建好、数据正常，这种写法在 PostgreSQL 和瀚高里仍会触发全表扫描——因为优化器无法将 integer 常量安全下推到索引扫描路径中，EXPLAIN 显示 type=Seq Scan 且 rows 等于全表行数。
- 正确写法只有两种：
WHERE is_active = true或WHERE is_active（后者更简洁，等价于= true） - MyBatis 中若参数是
Integer类型，#{active}会生成= ?占位符，但 JDBC 驱动仍按setInt()发送，最终执行时还是 integer 类型；必须改参数为Boolean并配jdbcType=BOOLEAN - MySQL 虽然允许
WHERE is_active = 1，但实际执行时会把每行is_active转成整数再比，B+ 树索引同样失效；现象是EXPLAIN中key=NULL
跨数据库迁移时布尔字段的语义漂移
MySQL 的 BOOLEAN 是 TINYINT(1) 别名，存的就是 0/1；PostgreSQL 的 boolean 是独立类型，只认 true/false 及其别名（t/f、yes/no 等）；SQL Server 根本没有 boolean 类型，常用 BIT 或 tinyint 模拟，但 WHERE flag = 1 在 BIT 列上仍可能触发隐式转换。
- 迁移脚本中所有
DEFAULT 0/DEFAULT 1必须全局替换为DEFAULT false/DEFAULT true - 应用层 ORM 映射需检查字段类型配置：Hibernate 的
@Column(columnDefinition = "boolean")比tinyint更安全；JDBC URL 加stringtype=unspecified可缓解部分驱动自动类型推断问题 - 前端传参如
?active=1，后端解析后必须转成布尔再传给 DAO，不能透传字符串或数字
最易被忽略的一点：JSON 字段里提取的布尔值（如 JSON_EXTRACT(data, '$.enabled')）返回的是字符串，即使内容是 "true"，跟 true 比较仍是字符串 vs 布尔，隐式转换照样发生。这时候连函数索引都救不了——必须用 CAST(JSON_EXTRACT(...) AS BOOLEAN) 显式转，且确保该字段上有函数索引。
