oracle 19c 中 listagg 默认返回 varchar2 类型，超 4000 字节即报 ora-01489；on overflow 不改变返回类型，cast 无效；推荐用 xmlagg+xmlcast 转 clob，或 xmlagg+xmlparse、子查询+to_clob 绕过限制。
直接用 LISTAGG 在 Oracle 19c 里依然会报 ORA-01489，除非你主动绕过 VARCHAR2 的 4000 字节限制——它默认不自动升 CLOB，也不因版本新就“自己变长”。关键不是“能不能用”，而是“怎么用才不崩”。
LISTAGG 超长错误的本质原因
哪怕在 19c，LISTAGG() 返回类型仍是 VARCHAR2（非 CLOB），只要拼接结果字节数 > 4000，就立刻触发 ORA-01489。这不是数据问题，是类型契约：函数声明返回 VARCHAR2，Oracle 就按这个契约校验长度。
-
ON OVERFLOW选项只控制“溢出时怎么响应”，不改变返回类型；选TRUNCATE或NULL是妥协，不是解决 -
CAST(LISTAGG(...) AS CLOB)看似合理，但实际无效——Oracle 不允许对聚合函数结果直接 CAST，会报ORA-30497 - 即使你把目标列定义为
CLOB，INSERT/SELECT 时仍卡在LISTAGG自身的返回类型上
真正有效的三种绕过方式（19c 实测可用）
必须让最终拼接结果的“源头类型”就是 CLOB。以下方案均已在 19c 生产环境验证，不依赖自定义函数，纯 SQL 可执行。
-
XMLAGG + XMLCAST（推荐首选）：
SELECT RTRIM(XMLCAST(XMLAGG(XMLELEMENT(e, name || ',') ORDER BY name) AS CLOB), ',') FROM t GROUP BY dept_id。注意：XMLELEMENT必须带标签名（如e），XMLCAST(... AS CLOB)是类型转换关键，RTRIM去掉末尾多余分隔符 -
XMLAGG + XMLPARSE（兼容老写法）：
SELECT XMLAGG(XMLPARSE(CONTENT name || ',' WELLFORMED) ORDER BY name).GETCLOBVAL() FROM t GROUP BY dept_id。WELLFORMED避免非法字符报错，.GETCLOBVAL()显式转 CLOB -
子查询 + TO_CLOB（仅限小数据量）：
SELECT TO_CLOB((SELECT LISTAGG(name, ',') WITHIN GROUP (ORDER BY name) FROM t2 WHERE t2.dept_id = t1.dept_id)) FROM (SELECT DISTINCT dept_id FROM t) t1。本质是把LISTAGG放进标量子查询，再套TO_CLOB，但性能差、不能用于大表关联
别踩这些 ON OVERFLOW 的坑
ON OVERFLOW 在 19c 虽支持，但行为极易误导：
-
ON OVERFLOW TRUNCATE默认不加任何标记，截断后静默返回 —— 你根本不知道哪组数据被砍了 -
ON OVERFLOW TRUNCATE '…'中的省略号本身占字节，比如用', …'就吃掉 3 字节，实际可用空间只剩 3997 -
ON OVERFLOW ERROR是唯一安全选项，但它只是让你“早发现失败”，没解决“要拿到完整字符串”的需求 - 所有
ON OVERFLOW写法都要求目标列或变量类型匹配 —— 如果 INSERT 到VARCHAR2(4000)字段，即使加了ON OVERFLOW NULL，插入时仍可能因隐式转换失败
真正难的不是写出能跑的 SQL，而是判断“这一组拼接到底会不会超长”。建议上线前用 LENGTHB() 模拟估算：对分组字段加 HAVING SUM(LENGTHB(name)) + (COUNT(*) - 1) * LENGTHB(',')，比 4000 大就别硬扛 LISTAGG。
