Oracle 23ai 中 BOOLEAN 是 SQL 层原生类型，但 PL/SQL 存储过程不支持其作为参数或表列在客户端使用；它适用于建模、WHERE 条件和 RETURNING，PL/SQL 内部仅限局部变量及 RETURNING 上下文。
Oracle 23ai 中的 BOOLEAN 是 SQL 层原生支持的类型，但 PL/SQL 存储过程中仍不能直接用它作为表列或参数传入/传出 SQL 语句 —— 这是初学者最容易误解的一点。
为什么 BOOLEAN 在存储过程中“看起来能用”，实际却受限？
23ai 确实让 BOOLEAN 进入了 SQL 表定义、WHERE 条件、CASE 表达式，甚至支持 INSERT 带 TRUE/FALSE 字面量。但 PL/SQL 的变量声明和参数类型系统并未同步升级：
-
BOOLEAN变量只能在 PL/SQL 块内使用（比如DECLARE is_active BOOLEAN := TRUE;），不能作为IN/OUT参数类型出现在存储过程签名中 -
CREATE TABLE t (flag BOOLEAN)合法，但SELECT flag FROM t在 SQL*Plus 或 JDBC 中会报ORA-00902: invalid datatype—— 因为客户端驱动尚未普遍适配该类型 - 试图在
EXECUTE IMMEDIATE中拼接BOOLEAN值，会触发隐式转换失败，实际走的是TO_CHAR或报错
真正能简化存储过程的用法：只在 SQL 层用，PL/SQL 层绕开
不要试图把 BOOLEAN 当作跨层通用类型。正确做法是：让 SQL 处理逻辑判断，PL/SQL 只做流程控制。
- 把布尔逻辑下推到
UPDATE ... WHERE flag = TRUE或SELECT ... WHERE status IS TRUE，避免在 PL/SQL 中写IF v_flag THEN ...冗余分支 - 用
SELECT CASE WHEN flag THEN 1 ELSE 0 END INTO v_int FROM ...把结果转成NUMBER或VARCHAR2再进 PL/SQL 流程 - 对外暴露的存储过程参数，坚持用
CHAR(1)（'Y'/'N'）或NUMBER(1)（1/0），这是最兼容、最不易出错的选择
BOOLEAN 列在 DML 和约束中的实际收益
它的价值不在过程体内部，而在数据建模和语义表达上：
-
ALTER TABLE orders ADD is_shipped BOOLEAN DEFAULT FALSE NOT NULL;比is_shipped CHAR(1) CHECK (is_shipped IN ('Y','N'))更直观、无歧义 -
WHERE is_shipped IS TRUE比WHERE is_shipped = 'Y'更安全 —— 不受大小写、空格、NULL 陷阱影响 - 配合
IF NOT EXISTS和RETURNING，可写出更紧凑的原子操作，例如：UPDATE orders SET is_shipped = TRUE WHERE id = 123 RETURNING is_shipped INTO v_result;，这里v_result是 PL/SQL 的BOOLEAN变量，但仅限于RETURNING子句这一处上下文
别指望靠 BOOLEAN 彻底重写旧存储过程。它真正起效的地方，是新建表结构、重构查询条件、以及减少 CHECK 约束和应用层映射的胶水代码 —— 这些地方改一点，比在 PL/SQL 里硬塞一个不被支持的类型要稳得多。
