在PostgreSQL里用crosstab()做行转列，第一步永远不是写SQL，而是确认tablefunc扩展装没装。别笑，这是翻车率最高的新手动作，直接报错“function does not exist”的时候，十有八九都是栽在这儿。
PostgreSQL中用crosstab()实现行转列必须装扩展
调crosstab()之前，先跑一句查询确认扩展是否加载：
SELECT * FROM pg_extension WHERE extname = 'tablefunc';
查不到结果？那就用超级用户身份安装：
CREATE EXTENSION IF NOT EXISTS tablefunc;
有句话说在前面：tablefunc在RDS这类托管服务上往往不能自动安装，有些云厂商需要你提工单或改参数组才能启用。真遇到这情况别硬扛，直接换方案。
crosstab()的SQL参数必须严格匹配三列结构
好，可以开始写SQL了吗？注意了，传给crosstab()的内层查询，必须严格返回三列，顺序和类型都别搞错：
- 第一列是分组依据，比如
user_id或product_name，后续会变成结果集的行 - 第二列是将来要变列的字段，比如
month或status，值必须是text类型（就算原始是int也得用::text强转） - 第三列是填充到交叉格子的数值，支持
text、int、numeric等，但整条结果不能混类
常见的翻车点有二：第二列用了enum或json类型，crosstab()直接拒绝；第三列数据里NULL和0混用，导致隐式类型转换失败。所以写SQL时养成习惯，第二列记得::text。
动态列名必须靠硬编码或应用层拼接
执着于动态列名怎么办？先说结论：crosstab()本身不负责动态生成列名，它按你写的RETURN TABLE(...)定义来返回结构。想让“2023-01”“2023-02”自动变成列？做不到。
两个现实方案：
- 能预知所有可能值时，手动写
RETURN TABLE(user_id int, "2023-01" numeric, "2023-02" numeric, ...) - 列名不确定时，先查一回所有分类值：
SELECT DISTINCT category::text FROM data ORDER BY 1，再用Python或Node.js把完整SQL拼出来
别妄想通过EXECUTE在函数里自动重构返回类型——PostgreSQL的函数返回结构在定义时就固化了，运行时不能变。
替代方案：用FILTER + GROUP BY更可控
再说一个我经常推荐的方案——如果只是少数几个固定维度（比如统计订单状态分布），用标准SQL的FILTER配合GROUP BY更稳：
SELECT user_id, COUNT(*) FILTER (WHERE status = 'paid') AS paid, COUNT(*) FILTER (WHERE status = 'shipped') AS shipped, SUM(amount) FILTER (WHERE status = 'refunded') AS refunded_total FROM orders GROUP BY user_id;
优势明显：既不需要tablefunc扩展，也不依赖任何第三方工具，兼容所有PostgreSQL版本。列名、类型完全由你定，执行计划一目了然，EXPLAIN能看明白每列怎么算的。
真正棘手的情况是列名非要动态而且数量巨大（比如按天统计365列），这时候就该考虑是不是SQL的活儿——把聚合逻辑下沉到应用层，或者换用OLAP引擎，都比你硬怼单一数据库靠谱得多。
