Oracle 23c虽引入原生BOOLEAN类型，但其仅限PL/SQL运行时使用，无法用于表列定义、SQL查询返回、JDBC绑定或权限系统（如DBA_TAB_PRIVS），因权限体系完全基于VARCHAR2/CHAR/NUMBER等SQL数据类型，BOOLEAN不能持久化或跨层传递。
Oracle 23c 原生支持 BOOLEAN 类型，但它**不能直接用于表列、视图、索引或权限相关系统视图的定义中**——所以它本身并不影响权限存储过程的逻辑或行为。真正容易混淆的点在于：开发者误以为 BOOLEAN 可以像其他数据类型一样参与 DCL（如 GRANT/REVOKE）或被存储过程返回给调用方做权限判断，而实际上它根本无法进入权限系统的持久化层。
为什么 BOOLEAN 不能用于权限判断逻辑？
Oracle 的权限体系（如 DBA_TAB_PRIVS、SESSION_PRIVS）全部基于字符串或数字字段（例如 GRANTEE 是 VARCHAR2，PRIVILEGE 是 VARCHAR2，ADMIN_OPTION 是 CHAR(1)）。BOOLEAN 是 PL/SQL 运行时类型，仅存在于 PL/SQL 引擎上下文中，无法：
- 作为表字段被持久化（建表时用
flg BOOLEAN会报ORA-00902: invalid datatype） - 出现在 SQL 查询结果集中（
SELECT my_func() FROM DUAL中若my_func返回BOOLEAN，会报PLS-00382: expression is of wrong type） - 被绑定到 JDBC/ODBC 等客户端驱动（驱动不识别
BOOLEAN，无法映射）
BOOLEAN 在存储过程中能做什么？
它只在纯 PL/SQL 范围内有效，适合简化内部逻辑分支。比如写一个权限校验封装函数：
CREATE OR REPLACE FUNCTION can_access_table(p_user VARCHAR2, p_table VARCHAR2) RETURN BOOLEAN IS
v_cnt NUMBER;
BEGIN
SELECT COUNT(*) INTO v_cnt
FROM DBA_TAB_PRIVS
WHERE GRANTEE = p_user AND TABLE_NAME = p_table AND PRIVILEGE = 'SELECT';
RETURN v_cnt > 0; -- ✅ 合法：PL/SQL 内部返回 BOOLEAN
END;但注意：这个函数**不能被 SQL 直接调用**。下面这句会失败：
SELECT can_access_table('SCOTT', 'EMP') FROM DUAL; -- ❌ PLS-00382必须包装成 NUMBER 或 VARCHAR2 才能暴露给 SQL 层：
CREATE OR REPLACE FUNCTION can_access_table_sql(p_user VARCHAR2, p_table VARCHAR2) RETURN NUMBER IS BEGIN RETURN CASE WHEN can_access_table(p_user, p_table) THEN 1 ELSE 0 END; END;
权限存储过程里该用什么替代 BOOLEAN？
如果你要写一个带权限判断的存储过程（比如 proc_grant_if_allowed），别试图用 BOOLEAN 作入参或出参。实际可用的方案只有：
- 用
CHAR(1)表示 Y/N，配合检查约束（CHECK (flag IN ('Y','N'))） - 用
NUMBER(1)表示 1/0，语义清晰且兼容所有接口 - 用异常机制代替返回值：权限不足时直接
RAISE_APPLICATION_ERROR(-20001, 'Insufficient privilege') - 如果真需要布尔语义，只在 PL/SQL 块内使用，比如
IF can_access_table(...) THEN ...，不对外暴露
最常被忽略的一点是：BOOLEAN 的“存在”不等于“可用”。它解决了 PL/SQL 内部逻辑表达的干净度问题，但没改变 Oracle 权限模型的数据契约——那套契约仍由 SQL 层的字符串和数字类型牢牢锚定。
