postgresql中setof后必须跟已存在的复合类型或表名，不能直接写table；推荐用create type定义命名行类型再配合setof使用，或直接用setof table_name（需结构严格匹配）；避免setof record。
PostgreSQL函数返回SETOF TABLE时，必须显式声明返回列结构
直接写 RETURNS SETOF TABLE 会报错：「syntax error at or near "TABLE"」。PostgreSQL 不支持运行时推导表结构，SETOF 后面必须是已存在的复合类型（如自定义 TYPE）或具体表名（如 SETOF users），不能是匿名 TABLE(...)。
常见错误现象：ERROR: syntax error at or near "TABLE" 或 ERROR: type "table" does not exist。
- 若想返回动态字段组合，需提前用
CREATE TYPE定义命名行类型 - 若结果集对应某张物理表，直接用
RETURNS SETOF my_table最稳妥，且能自动继承列名、类型、NOT NULL 约束 - 若只是临时组合几列（如
id int, name text），定义一个一次性TYPE更清晰，比硬编码到函数体里更易维护
用CREATE TYPE配合SETOF实现可控的行结构返回
这是最常用也最安全的方式：先建类型，再在函数中引用。它让调用方能准确获取列信息（比如 JDBC/psycopg2 能正确映射字段），也避免了 RETURN QUERY SELECT * 可能导致的列顺序/类型不一致问题。
示例：
CREATE TYPE user_summary AS (
user_id int,
full_name text,
order_count bigint
);
<p>CREATE OR REPLACE FUNCTION get_active_users()
RETURNS SETOF user_summary AS $$
SELECT u.id, u.first_name || ' ' || u.last_name, COUNT(o.id)
FROM users u
LEFT JOIN orders o ON o.user_id = u.id AND o.status = 'paid'
WHERE u.is_active = true
GROUP BY u.id, u.first_name, u.last_name;
$$ LANGUAGE sql;</p>
- 类型名
user_summary必须全局唯一，建议加业务前缀 - 函数体内
SELECT的列数、顺序、类型必须与TYPE完全匹配，否则运行时报错structure of query does not match function result type - 不需要在函数里写
RETURN语句——SQL 函数中RETURN QUERY或直接写SELECT即可隐式返回
用RETURNS SETOF table_name省去类型定义，但有隐含约束
如果结果集恰好和某张表（或视图）结构一致，直接用 RETURNS SETOF my_table 是最快捷的方式，PostgreSQL 会自动把该表的列定义作为函数返回结构。
示例：
CREATE OR REPLACE FUNCTION get_recent_posts(days_ago int DEFAULT 7)
RETURNS SETOF posts AS $$
SELECT * FROM posts
WHERE created_at >= NOW() - INTERVAL '1 day' * days_ago
ORDER BY created_at DESC;
$$ LANGUAGE sql;
- 必须确保
SELECT *返回的每一列都存在于posts表中，且顺序一致；加别名、计算列、缺失列都会触发结构不匹配错误 - 如果
posts表后续被ALTER TABLE ... ADD COLUMN，函数调用不会自动包含新列——因为SETOF posts绑定的是定义时的快照结构 - 不推荐用于跨 schema 表，除非明确指定
RETURNS SETOF myschema.posts，否则可能因 search_path 导致解析歧义
不要用SETOF record，除非你控制所有调用上下文
RETURNS SETOF record 要求每次调用时都用 AS 显式指定列定义，例如 SELECT * FROM get_data() AS t(id int, name text)。一旦漏写或写错，立刻报错 column definition list is required for functions returning "record"。
- 这种写法把结构契约从函数定义层转移到了调用层，极易出错，不适合 API 化或被其他函数复用
- ORM（如 SQLAlchemy、Django ORM）通常无法自动推导
record类型，会导致查询失败或字段丢失 - 仅适合临时调试或极简脚本，生产代码中应避免
真正麻烦的地方不在怎么写，而在于类型定义和函数体之间那层脆弱的契约——改一行 TYPE 字段，就可能让十几个调用点全部崩掉。所以定义 TYPE 时多花三十秒加注释，比事后查两小时 structure mismatch 强得多。
