pl/sql函数返回表类型必须使用pipelined关键字，声明return table of已定义的object类型集合，函数体内仅允许pipe row()逐行输出，调用时须用table()包装，否则报pls-00653错误。
PL/SQL函数怎么返回表类型？用 PIPELINED 是最常用且实用的方式
Oracle 不允许普通函数直接返回嵌套表或 VARRAY 类型（会报 PLS-00653: aggregate/table functions not allowed in this context），必须配合 PIPELINED 关键字，让函数以“流式”方式逐行输出。这不是语法糖，而是强制要求——否则 SQL 层根本无法查询该函数结果。
常见错误是写成普通函数 + RETURN my_table_type，然后在 SELECT * FROM TABLE(my_func()) 中调用，结果直接报错。关键点在于：只有 PIPELINED 函数才能被 TABLE() 包装后参与 SQL 查询。
PIPELINED 函数的结构和必须满足的条件
它不是简单加个关键字就行，结构有硬性约束：
- 返回类型必须是已定义的集合类型（如
my_obj_table_type），且该类型元素类型需对应一个OBJECT类型 - 函数体内不能用
RETURN返回整个集合，只能用PIPE ROW(...)逐行推送 - 函数末尾可选加一个
RETURN;（不带值），表示结束流；不加也不会报错，但建议显式写出 - 不能有
OUT或IN OUT参数，所有参数必须是IN
示例骨架：
CREATE OR REPLACE TYPE my_obj AS OBJECT (id NUMBER, name VARCHAR2(50)); CREATE OR REPLACE TYPE my_obj_table_type AS TABLE OF my_obj; <p>CREATE OR REPLACE FUNCTION get_data RETURN my_obj_table_type PIPELINED IS BEGIN FOR r IN (SELECT id, name FROM users WHERE rownum </p>
为什么不用 REF CURSOR？什么场景下该选它
REF CURSOR 虽然也能“返回结果集”，但它本质是游标句柄，不能直接用 TABLE() 查询，必须由调用方（如应用代码）显式打开、遍历。而 PIPELINED 函数能无缝接入 SQL，比如做 JOIN、FILTER、聚合等。
选 REF CURSOR 的典型场景：
- 函数逻辑复杂，需动态拼 SQL 或多分支查询，且不希望暴露中间表结构
- 调用方是 Java/Python 等外部程序，本身处理游标更自然
- 要避免 PL/SQL 和 SQL 引擎之间反复切换开销（
PIPELINED每次PIPE ROW都有上下文切换）
注意：REF CURSOR 函数不能用于视图定义或物化视图刷新，而 PIPELINED 可以（只要权限和稳定性满足）。
性能与兼容性容易被忽略的坑
PIPELINED 函数不是银弹。实际用的时候得盯紧这几处：
- 函数内不能有 DML（INSERT/UPDATE/DELETE），否则报
ORA-14551: cannot perform a DML operation inside a query；如真需要，得加PRAGMA AUTONOMOUS_TRANSACTION，但会失去事务一致性 - Oracle 12c+ 支持并行管道函数（加
PARALLEL_ENABLE），但需确保函数逻辑线程安全，且集合类型必须是NOT NULL元素（否则并行时可能出空指针） - 如果函数里查的是大表，又没加适当谓词，
PIPE ROW会一行行推，但 SQL 引擎可能仍会全表扫描后再过滤——记得把过滤条件尽量下推到函数内部的 SELECT 中 - 调试困难：无法在 SQL Developer 的“测试窗口”里直接看管道函数输出，得用
SELECT * FROM TABLE(my_func())才能看到，且无断点调试能力
真正上线前，务必在真实数据量级下测执行计划和内存占用，尤其当函数被频繁 JOIN 或嵌套调用时——管道函数的“懒加载”特性反而可能掩盖资源瓶颈。
