PIPELINED函数必须返回TABLE OF自定义对象类型，禁用内置集合类型；函数体内只能用PIPE ROW推送数据，禁止RETURN语句；不可执行DML操作；应避免长生命周期游标，优先使用隐式游标。
PIPELINED函数必须搭配RETURN类型为TABLE OF自定义对象类型
Oracle不支持直接返回嵌套表或VARRAY的PIPELINED函数——必须先用CREATE OR REPLACE TYPE定义一个OBJECT类型，再基于它创建TABLE类型。常见错误是试图返回sys.odcivarchar2list等内置集合类型，这会导致编译失败：PLS-00653: aggregate/table functions not allowed in this context。
正确做法：
- 定义对象类型：
CREATE OR REPLACE TYPE emp_row AS OBJECT (empno NUMBER, ename VARCHAR2(10)) - 定义表类型：
CREATE OR REPLACE TYPE emp_table AS TABLE OF emp_row - 函数声明中明确写：
RETURN emp_table PIPELINED
PIPELINED函数体里只能用PIPE ROW不能用RETURN
这是最常踩的坑：在函数体内写RETURN emp_table()或RETURN NULL会直接报错PLS-00713: RETURN statement must be the last executable statement。PIPELINED函数的控制流由PIPE ROW驱动，每调用一次就向结果集“推送”一行，函数本身最终以END自然退出，不返回值。
典型结构：
FUNCTION get_emps RETURN emp_table PIPELINED IS
BEGIN
FOR r IN (SELECT empno, ename FROM emp WHERE deptno = 10) LOOP
PIPE ROW(emp_row(r.empno, r.ename)); -- 必须用PIPE ROW
END LOOP;
-- 这里不能写 RETURN
END;
不能在PIPELINED函数里做DML操作（INSERT/UPDATE/DELETE）
Oracle限制PIPELINED函数必须是READ ONLY的——如果函数内部执行了DML，调用时会报错：ORA-14551: cannot perform a DML operation inside a query。这不是权限问题，而是执行模型决定的：SQL引擎在执行SELECT * FROM TABLE(my_pipelined_func())时，会并发拉取多行，DML会破坏一致性。
绕过方法有限且需谨慎：
- 若真需写日志，可用
PRAGMA AUTONOMOUS_TRANSACTION开自治事务（但会丢失主事务上下文） - 更稳妥的做法是把DML逻辑拆到调用方，用
FOR UPDATE游标+循环处理 - 避免在函数内调用含DML的子过程
性能关键点：避免在PIPELINED函数中打开长生命周期游标
PIPELINED函数被设计为“边生成边消费”，但如果在函数开头就用OPEN cur FOR ...并长期持有游标句柄，而下游SQL因过滤条件（如WHERE rownum < 10）只取前几行，Oracle仍会执行完整查询逻辑——游标没被及时关闭，资源泄漏风险高。
建议写法：
- 优先用隐式游标（
FOR r IN (SELECT ...)），Oracle自动管理生命周期 - 若必须显式游标，确保在
EXIT WHEN cur%NOTFOUND后立即CLOSE cur - 对大数据量场景，考虑加
DBMS_APPLICATION_INFO.SET_SESSION_LONGOPS暴露进度，方便监控卡顿
PIPELINED函数真正的复杂性不在语法，而在它把“过程式逻辑”塞进了“声明式SQL管道”——一旦涉及状态维持、异常恢复或跨会话共享资源，就容易失控。多数时候，先确认是否真的需要流式（比如前端分页拉取），还是用物化视图或临时表更稳。
