凌晨一点，迁移脚本写到一半，数据库直接甩过来一行红字：ERROR: column “is_active” is of type boolean but default expression is of type integer。第一反应是"我又写错类型了"，但盯着看了半天，DEFAULT 1 明明是布尔值常用的写法，怎么到 PostgreSQL 这里就不认账？说实话，这条报错几乎每个从 MySQL 迁到 PostgreSQL 的团队都会撞上一次，很多人在网上搜了一圈，找到的答案还自相矛盾。今天我把它讲透：报错的真正原因、五种修复方案、以及那些"看似对但实际上会把你带沟里"的坑。
1. 报错出现的位置：你会在哪些操作里和它撞上
先说结论，这条报错不是一个孤立现象，它通常出现在三种操作里，表现形式差不多，但本质略有区别。
1.1 CREATE TABLE 阶段就翻车
最常见的场景是建表语句里给布尔列设了默认值：
CREATE TABLE user_account ( id BIGSERIAL PRIMARY KEY, username TEXT NOT NULL, is_active BOOLEAN DEFAULT 1 );执行到is_active BOOLEAN DEFAULT 1这一行，PostgreSQL 会直接拒绝整条语句。注意，不是跳过默认值、也不是帮你转成 true，而是整张表都建不出来。
1.2 ALTER TABLE 阶段补默认值
另一个高频场景是表已经存在，DBA 想给布尔列补一个默认值：
ALTER TABLE user_account ALTER COLUMN is_active SET DEFAULT 0;一样会报错。这个错误文本和 CREATE TABLE 场景几乎完全一致，因为 PostgreSQL 在解析SET DEFAULT子句时，对默认表达式做的类型检查和建表时是同一条逻辑。
1.3 INSERT 语句里直接给布尔列塞 0/1
这个稍微隐蔽一点，它虽然不是在 default expression 上出问题，但报错信息非常像：
INSERT INTO user_account (username, is_active) VALUES ('zhangsan', 1);报错文本是：
ERROR: column "is_active" is of type boolean but expression is of type integer HINT: You need to rewrite or cast the expression.注意区别：建表/ALTER 时报的是 "default expression is of type integer"，INSERT 时报的是 "expression is of type integer"，少了 default 两个字。原因是这里没有默认表达式的参与，是值本身类型不匹配。但很多人把这两条报错混在一起搜，反而越搜越乱。
再把错误文本本身拆开看：column "is_active" is of type boolean but default expression is of type integer。这句话已经把答案说了三层：你的列是布尔类型，默认表达式算出来是整型，这两者 PostgreSQL 不接受。等于是数据库在教你做人——它不是不能存 0/1，而是"你的写法没有经过它的类型系统许可"。
2. 根因拆解：PostgreSQL 为什么敢这么"不给面子"
很多人第一次遇到这个报错的第一反应是："这数据库怎么这么死板？"其实 PostgreSQL 的死板背后是一套严谨的类型系统。理解这套系统，之后遇到所有类似的类型不匹配问题都能举一反三。
2.1 强类型系统下的隐式转换规则
PostgreSQL 是出了名的强类型数据库。它的类型体系里存在一种叫做"赋值转换"（assignment cast）的东西，只有这种转换存在时，一个类型的值才能被自动当作目标类型使用。
画个不严谨但好理解的类比：MySQL 像一家不拘小节的便利店，你递过去 1，它自动当成 true 收了；PostgreSQL 更像机场安检，你的登机牌写的是"整型旅客"，就绝不能进"布尔候机区"，除非你有明确的转乘凭证（显式 CAST）。
在pg_cast系统表里，integer到boolean之间没有注册任何隐式转换。这意味着：
integer -> boolean不行boolean -> integer也不行- 两边都不存在隐式转换的渠道
2.2 DEFAULT 子句的本质：它是一个表达式，不是一个常量
这里有个非常容易误解的点：你以为在写DEFAULT 1，是在"存一个值"；但 PostgreSQL 眼中的DEFAULT是一个默认表达式，它会在每次插入语句没提供该列值时被重新求值。
因为是表达式，PostgreSQL 必须保证它的求值结果能被赋值给目标列。二进制位能对上不算数，类型系统说不行就是不行。所以DEFAULT 1这种写在 MySQL 里顺理成章的事情，到 PostgreSQL 就直接被卡在类型检查这一关。
2.3 反直觉的关键点：1 是 integer，'1' 却是"身份待定"
绝大多数人没有注意到1和'1'在 PostgreSQL 里是两个完全不同的东西：
1是整数常量，类型直接就定了，是integer。'1'是字符串常量，在没有明确目标类型时，PostgreSQL 管它叫unknown（未知类型）。
这也就是为什么DEFAULT '1'能通过，而DEFAULT 1会报错：
-- 能通过 CREATE TABLE demo_ok (b BOOLEAN DEFAULT '1'); -- 报错 CREATE TABLE demo_fail (b BOOLEAN DEFAULT 1);'1'因为是未知类型，PostgreSQL 在把它赋给 BOOLEAN 列时，会尝试调用 boolean 类型的输入函数。而 boolean 的输入函数恰好接受'1'和'0'作为 true/false 的合法文本表示，于是成功转换。
这里再补充一个已经有人踩过的二次坑：很多文章告诉你"加个 CAST 不就行了吗"，于是你兴冲冲地写：
CREATE TABLE demo_cast (b BOOLEAN DEFAULT 1::boolean);结果又收到报错：
ERROR: cannot cast type integer to boolean注意，PostgreSQL没有注册 integer 到 boolean 的显式 CAST。1::boolean这条路根本走不通。想转换的话必须先通过文本，比如'1'::boolean，或者用比较表达式(1 = 1)这种返回布尔值的写法。这一点在网上很多旧帖子里是错着传的，你搜到这个答案时一定要留意。
2.4 PostgreSQL 眼中合法的布尔"文本"到底有哪些
既然说到 boolean 的输入函数，干脆把规则列全。PostgreSQL 文档里关于 boolean 类型的合法输入有两大类：
| 逻辑值 | 合法字面量（大小写不敏感） | 典型 SQL 写法 |
|---|---|---|
| true | TRUE, t, true, y, yes, on, 1 | DEFAULT true/DEFAULT '1' |
| false | FALSE, f, false, n, no, off, 0 | DEFAULT false/DEFAULT '0' |
你可以在 psql 里验证一下：
SELECT '1'::BOOLEAN AS a, '0'::BOOLEAN AS b, 'yes'::BOOLEAN AS c, 'off'::BOOLEAN AS d;会得到a=true, b=false, c=true, d=false。所以结论很清晰：不是 PostgreSQL 不接受 0/1，而是它接受的是文本形态的 '0'/'1'，当 0/1 以整数字面量出现时，它不背这个锅。
3. 五种修复方案的完整对比，以及哪个更适合你
明确了根因之后，修复方式其实绕不开五条路。我按推荐程度从高到低逐个拆解。
3.1 方案一：用布尔字面量 true/false（最推荐）
直接把你脑子里的 1/0 翻译成数据库的 true/false，语义最清晰，也完全符合 SQL 标准：
CREATE TABLE user_account ( id BIGSERIAL PRIMARY KEY, username TEXT NOT NULL, is_active BOOLEAN DEFAULT true );这种写法无论在 PostgreSQL、Oracle、SQL Server 里都能跑，不会出现跨数据库方言的问题。代码审查的人也一眼能看懂。缺点几乎没有，唯一要克服的是你"1 代表启用"的旧习惯。
3.2 方案二：用字符串 '1'/'0'（能跑，但有隐患）
CREATE TABLE user_account ( id BIGSERIAL PRIMARY KEY, username TEXT NOT NULL, is_active BOOLEAN DEFAULT '1' );这条语句能成功执行，因为'1'是 unknown 类型，被 boolean 的输入函数吃进去了。但我个人不太推荐把这种写法留在生产环境里，原因有两个：
- 它利用了 boolean 类型"文本输入规则"这个隐性知识，读者未必知道
'1'等于 true，过两个月你自己看也会愣一下。 - 如果哪天这张表的 DDL 被某个 ORM 工具自动分析，工具可能把这个默认值识别成字符串，而在类型映射时又产生新的不一致。
当然，作为快速解决问题的手段，它比方案一更贴近"改一行就完事"的诉求，应急是完全可以的。
3.3 方案三：用比较表达式，把整型转成布尔（不推荐用于 DEFAULT）
遇到需要从现有 integer 列推导出布尔值的场景——比如某列原来是用 smallint 记录的，你想把它变成布尔列——可以用USING关键字配合比较表达式：
ALTER TABLE user_account ALTER COLUMN is_active TYPE BOOLEAN USING (is_active <> 0);这里is_active <> 0返回一个真正的 boolean 值，PostgreSQL 才会放行。不过这种写法用于 DEFAULT 默认值就很怪了：
-- 技术上可行，但没人会这么写 is_active BOOLEAN DEFAULT (1 = 1)我不建议把 DEFAULT 写成这种绕圈子的样子。真正优雅的是：如果业务状态本身有"启用/禁用/待审"等超过两个状态，那就不应该用布尔，直接改成整数或者枚举类型，从源头避免错配。
3.4 方案四：重新评估列类型，布尔是不是你的本意
聊到底我们要回头想一个问题：这个字段真的应该是 boolean 吗？如果在 MySQL 里它是TINYINT(1)，那 MySQL 本质上只是个整数。你迁到 PostgreSQL 后，完全可以保留SMALLINT，或者如果状态多于两种，用枚举类型甚至关联表更合适：
CREATE TABLE user_account ( id BIGSERIAL PRIMARY KEY, username TEXT NOT NULL, status SMALLINT NOT NULL DEFAULT 1 -- 0=禁用, 1=启用, 2=待审 );这样既绕开了类型不匹配，也让数据模型更贴合业务。我见过不少团队在迁移时"为了布尔而布尔"，反而把原来的整型语义砍掉了一半。
3.5 方案五：如果表已经建好并且带数据，怎么补丁式修复
假设你的表已经用别的类型建好了，想要把它转成 boolean 并带上默认值，需要分两步走：
-- 第一步：先把列类型转成 boolean，用 USING 子句处理已有数据 ALTER TABLE user_account ALTER COLUMN is_active TYPE BOOLEAN USING (is_active <> 0); -- 第二步：再设置布尔默认值 ALTER TABLE user_account ALTER COLUMN is_active SET DEFAULT true;注意：如果表里已经有大几百万行数据，
ALTER TABLE ... TYPE会重写整张表，期间会锁表。生产环境要考虑窗口期，或者使用pg_repack之类的工具。这是另一个话题了，但必须以提醒的方式说一句。
五种方案放在一起对照：
| 方案 | 写法 | 是否推荐 | 适用场景 |
|---|---|---|---|
| 布尔字面量 | DEFAULT true | 强烈推荐 | 新建表、修改默认值 |
| 字符串字面量 | DEFAULT '1' | 应急可用 | 快速绕过报错，兼容迁移脚本 |
| 比较表达式 | DEFAULT (1 = 1) | 不推荐 | 无，技术练习 |
| 改列类型 | SMALLINT DEFAULT 1 | 视业务而定 | 状态多于两三种时 |
| USING 转换 + 布尔默认值 | USING (col <> 0) | 推荐 | 存量整数列改为布尔列 |
4. 最容易踩的隐形坑：迁移场景里的连环爆炸
这一节我说几个真实环境里遇到的连环报错场景。只解决 default expression 这一个问题是不够的，因为你的坏习惯往往不止出现在建表语句里。
4.1 场景一：从 MySQL 迁到 PostgreSQL，DDL 直接废弃
MySQL 里的BOOLEAN其实只是TINYINT(1)的别名，所以下面这段 DDL 在 MySQL 里完全合法：
CREATE TABLE user_account ( is_active BOOLEAN DEFAULT 1 );它在 MySQL 里创建的是一个小整数，默认值 1 当然没问题。但同一份 DDL 拿到 PostgreSQL 里，第一行就报你看到的错。
这种问题往往不是一个表，而是一整个 schema 里有二三十张表都这么写。修复思路不是一张表一张表去手改，而是在迁移工具里做一个全局替换规则：把BOOLEAN DEFAULT 1替换成BOOLEAN DEFAULT true，把BOOLEAN DEFAULT 0替换成BOOLEAN DEFAULT false。如果你们用的 Flyway，那就直接在迁移脚本里统一处理。
4.2 场景二：ORM 自动生成的 DDL 里藏着 MySQL 方言
Java 的 Hibernate 如果配置了hibernate.dialect=org.hibernate.dialect.MySQLDialect，它在自动建表时可能会生成bit或tinyint类型的列，默认值写成 1/0。切到 PostgreSQL 方言后，有些情况下还是会在保存实体时因为类型不匹配报错。
这里给我的经验有两条：
- 尽量不要靠 ORM 的
ddl-auto=update去管理生产库的表结构，迁移脚本和版本控制才是正道。 - 如果不得不用
columnDefinition，直接用 PostgreSQL 的写法，别把 MySQL 的 TINYINT(1) 带过来：
@Column(columnDefinition = "boolean default true") private Boolean isActive;4.3 场景三：你以为只有 DDL 有问题？查询语句也在爆炸
迁移之后，你千辛万苦把 default expression 修好了，结果应用一启动，日志里刷出这种错误：
ERROR: operator does not exist: boolean = integer LINE 1: SELECT * FROM user_account WHERE is_active = 1;这其实是同一个根因的第二波爆炸。PostgreSQL 里WHERE is_active = 1是行不通的，因为 boolean 和 integer 之间不存在=运算符。正确写法是：
SELECT * FROM user_account WHERE is_active; SELECT * FROM user_account WHERE is_active = true; SELECT * FROM user_account WHERE is_active IS TRUE;所以做迁移时不要只看建表语句，所有跟这个布尔字段相关的查询条件都要全局搜一遍。Java、Python、PHP 代码里的where is_active = 1、where is_active = 0全部要改。
4.4 场景四：ETL 管道里灌数字类型
公司里如果走了 DataX、Kettle 或者自研 ETL 工具，源端导出的是0/1的整数，目标端 PostgreSQL 表是 boolean 列，INSERT 或 COPY 的时候也会报同样的类型错误。
处理起来就两条路：
- ETL 脚本层面做一次转换，把整数列先转成 varchar 的
'0'/'1'，PostgreSQL 可以按文本吃进去； - 或者目标表暂时保留 smallint，到最终落库的层再转布尔。
千万别想着直接SET column = 1，PostgreSQL 的高墙只认合法路径，绕不过去。
5. 一次完整排查：从报错到修复的实操链路
这节我带你把排查过程完整走一遍，方便你下次遇到时不用再百度。
5.1 第一步：从报错信息里提取三个关键信息
假设你执行一条迁移脚本时看到了这样的报错：
ERROR: column "is_active" is of type boolean but default expression is of type integer LINE 5: is_active BOOLEAN DEFAULT 1我要你做三件事：
- 看
column "is_active"，确认是哪一列出的问题； - 看
is of type boolean，确认该列的目标类型； - 看
default expression is of type integer，确认默认表达式的类型。
这三条信息直接告诉你矛盾双方是谁。大部分情况下，问题就出在DEFAULT后面的那个常量的写法上。
5.2 第二步：千万别急着搜"1::boolean"这种神仙答案
我第一次遇到时也走了弯路。当时搜到一个高赞回答，说"加个 CAST 就好"，我照着写了：
ALTER TABLE user_account ALTER COLUMN is_active SET DEFAULT 1::boolean;结果报错变成：
ERROR: cannot cast type integer to boolean这条报错本身就是一个极其重要的线索：PostgreSQL 根本不提供 integer 到 boolean 的 CAST。也就是说，你想"显式转一下"都没有入口。网上很多文章是把 MySQL 或 SQL Server 的经验搬过来的，在 PostgreSQL 这里水土不服。
5.3 第三步：用\d+查看列和默认值的实际存储
如果报错发生在你"接手别人留下的脚本"时，先用 psql 看一眼当前列的定义：
\d+ user_account\d+输出里会列出所有列的类型、默认值、统计信息等。如果列类型已经是 boolean，而默认值显示的是1或者0，那基本锁定了矛盾点。
5.4 第四步：用最小复现确认根因
强烈建议你在分析环境里建一个最小化复现，避免在生产库上反复试错：
-- 最小复现：确认报错 CREATE TABLE debug_bool_fail ( b BOOLEAN DEFAULT 1 ); -- 对比验证：字符串形式可过 CREATE TABLE debug_bool_ok ( b BOOLEAN DEFAULT '1' ); -- 对比验证：字面量可过 CREATE TABLE debug_bool_ok2 ( b BOOLEAN DEFAULT true );用最小复现把变量控制在"默认值写法"这一个维度上，你就能非常确定问题出在哪里，而不是在生产环境的几十个报错信息里猜。
5.5 第五步：按业务场景选择修复方案并验证
如果只是新建表，直接改成DEFAULT true即可：
CREATE TABLE user_account ( id BIGSERIAL PRIMARY KEY, username TEXT NOT NULL, is_active BOOLEAN NOT NULL DEFAULT true );如果表已经存在、且已有存量数据，用前面讲的两步法：
ALTER TABLE user_account ALTER COLUMN is_active TYPE BOOLEAN USING (is_active <> 0); ALTER TABLE user_account ALTER COLUMN is_active SET DEFAULT true;最后验证一把，确认默认值正确生成：
-- 不指定 is_active，测试默认值 INSERT INTO user_account (username) VALUES ('wangwu') RETURNING id, is_active; -- 指定 true/false，确认显式赋值也不受影响 INSERT INTO user_account (username, is_active) VALUES ('zhaoliu', false) RETURNING id, is_active;5.6 排查链路小结
整个排查过程说白了就是三步：定位到列 → 对比类型 → 重写默认表达式。不要被报错里长长的英文吓到，它其实是 PostgreSQL 对类型系统最坦诚的自白。
6. 防患于未然：给团队几条能落地的小规范
这类问题处理过一次之后，最好在团队层面做一个预防机制，不然过两个月换个项目又会踩一脚。
6.1 代码审查时盯住 DDL 里的 DEFAULT 写法
凡是涉及 PostgreSQL 的建表语句，审查时重点看两类：BOOLEAN DEFAULT 0/1和WHERE 布尔列 = 0/1。这两种写法在 MySQL 语境里能跑，到了 PostgreSQL 全是雷。可以把它们写进团队的 SQL 规范里，甚至做一个静态检查规则。
6.2 ORM 层面统一用语言原生布尔类型
Java、Python、Go 这些语言里，实体字段声明为Boolean、bool，让 ORM 自己处理类型映射。不要在 Java 代码里给布尔字段塞Integer再让 Hibernate 去猜。真要用默认值，也是在实体字段上写@Column(columnDefinition = "boolean default true")，而不是"boolean default 1"。
6.3 迁移项目里的全局搜索清单
从 MySQL 迁移到 PostgreSQL，我建议把下面这些模式加入全局搜索清单：
BOOLEAN DEFAULT [0|1]、BOOL DEFAULT [0|1]、TINYINT(1) DEFAULT [0|1]WHERE [a-z_]* = [0|1]且该列在 PG 里最终会变成 boolean 类型SET [a-z_]* = [0|1]，同样针对目标为 boolean 列的场景- ORM 实体类里的
columnDefinition中含有TINYINT(1)或BIT(1)
6.4 用 pg_dump 作为权威参照
如果你不确定某段 DDL 在 PostgreSQL 里会不会出问题，最权威的做法是：在 PG 里先手工创建一个理想表，然后用pg_dump --schema-only导出它的 DDL，拿它当模板。比如你创建一个带DEFAULT true的表，dump 出来的内容就是 PostgreSQL 认为"标准"的写法。团队内部可以直接把这种 dump 结果作为代码生成的蓝本。
说实话，这类报错在 PostgreSQL 的日常开发里真的不算稀奇。我个人遇到最多的情况，是那些从 MySQL 迁过来的老系统，几十张表里但凡和布尔沾边的字段，几乎都带着DEFAULT 1的影子。修掉 default expression 之后，WHERE is_active = 1的查询还会继续出来刷存在感，所以做这种排查时我的习惯是"一次把所有关联代码都过一遍"，不要只处理数据库这一层就收工。
最后再分享一个小技巧：在 psql 里给常用搜索做个快捷键或者别名，把SELECT * FROM pg_attribute WHERE attname = '你的列名';存起来，排查类型问题时能省一半时间。毕竟 PostgreSQL 的报错虽然严格，但也正是这种严格，逼着我们在一开始就写下更清晰的表结构。这样一想，被它"教育"一次也不算亏。