PostgreSQL中stored procedure为何无法返回表全列

核心原因是两者从设计之初的定位、语法支持、执行链路上就有本质区别，不是谁好谁坏，是适用场景完全不一样：

• 首先是设计定位的根本差异
  PostgreSQL的存储过程（PROCEDURE）是11版本才新增的对象，从一开始就是为了支持带事务控制的批处理操作设计的：你可以在存储过程里写COMMIT、ROLLBACK，做批量数据变更、DDL执行这类有副作用的串行操作。它的调用入口只有CALL语句，天生就不支持把自己嵌在SELECT ... FROM后面当作关系表来消费，根本就不是为了返回可复用的结构化结果集做的设计。
  而函数（FUNCTION）是PostgreSQL从初始版本就支持的对象，定位就是SQL逻辑的可复用封装，天然支持嵌入到任意SQL表达式、表引用位置，天生就是用来返回计算结果、结果集的。
• 其次是表结构返回的原生支持差距极大
  如果要返回某张表的所有列，函数有零成本的适配语法：你不需要手动逐列声明字段名和类型，只要把返回类型写成RETURNS SETOF 目标表名就可以，函数返回的结构会自动和目标表的列定义完全对齐——后续表加字段、改字段类型，只要函数内部查询逻辑适配，不需要手动修改函数的返回定义，维护成本极低。
  存储过程根本没有RETURNS子句的设计，要返回列只有两种方案：要么逐列写OUT参数，表有多少列你就得手动写多少个参数定义，表结构改了你还得同步改存储过程的参数列表，几十列的表维护起来非常麻烦；要么返回REF CURSOR游标，需要客户端单独维护游标句柄拉取数据，完全做不到像查普通表那样直接SELECT *拿全列数据。
  虽然存储过程内部也支持写RETURN QUERY返回查询结果，但这个能力是用来返回过程执行的状态、统计类临时信息的，返回的结果不能直接被SQL查询链路消费，和函数返回集合类型的能力不是一个层面的东西。
• 最后是执行优化和使用体验的差距
  返回集合的函数可以被PostgreSQL查询优化器正常识别：标记为STABLE/IMMUTABLE的函数可以被做常量折叠、条件下推，你写SELECT * FROM your_func() WHERE id = 100的时候，优化器甚至可以把过滤条件下推到函数逻辑里，执行效率和直接查原表差距很小。而且返回的结果集可以直接做JOIN关联、分组聚合、排序、视图封装，和操作普通物理表的体验完全一致。
  存储过程因为内部可以包含事务控制、DDL、隐式副作用，优化器完全没法对它的执行逻辑做解析和优化，更不可能把它的输出当作关系表和其他SQL逻辑拼接，想要处理存储过程返回的数据，只能先把结果落临时表，多了一层不必要的IO和开发成本，完全不适合做表全列返回的场景。

简单总结：如果你的目的是封装一段查询逻辑、返回可以像表一样被SQL消费的结构化结果，选函数；如果你的目的是封装一段带事务控制的批处理、数据变更逻辑，不需要把结果嵌入SQL查询链路，再选存储过程。

内容的提问来源于stack exchange，提问作者Tejas Mankar