crosstab()报错因未启用tablefunc扩展，需先执行CREATE EXTENSION IF NOT EXISTS tablefunc；其输入SQL须返回严格三列（rowid/category/value）并ORDER BY 1,2，第二参数决定列数与顺序，类型必须完全匹配。
为什么直接用 crosstab() 会报错“function crosstab(unknown) does not exist”
PostgreSQL 默认不自带 crosstab()，它属于 tablefunc 扩展。没启用就调用，就会触发这个错误。必须先手动加载扩展，且需有创建权限：
- 连接到目标数据库后，执行
CREATE EXTENSION IF NOT EXISTS tablefunc; - 如果提示“permission denied”，说明当前用户没有
CREATE权限，需由超级用户或拥有该权限的用户执行 - 扩展只需在每个数据库中运行一次，不是每次查询都要加载
写 crosstab() 查询时，内层 SQL 必须严格满足三列顺序：行标识、分类列、值列
crosstab() 的输入 SQL（第一个参数）必须返回**恰好三列**，且顺序固定：rowid、category、value。列名可以任意，但位置不能错。常见翻车点：
- 漏掉
ORDER BY 1,2——crosstab()要求输入按行标识升序、再按分类列升序，否则结果错乱甚至报错more than one row returned by a subquery used as an expression - 把聚合写在内层却没
GROUP BY，导致每组多行，破坏三列结构 - 分类列含
NULL或不可排序类型（如json），会中断执行
正确示例（销售数据按地区和产品汇总）：
SELECT * FROM crosstab( 'SELECT region, product, SUM(sales) FROM sales GROUP BY region, product ORDER BY 1,2', 'SELECT DISTINCT product FROM sales ORDER BY 1' ) AS ct(region text, "Widget A" numeric, "Widget B" numeric, "Gizmo" numeric);
第二参数（分类值列表）缺失或类型不匹配会导致列数对不上
crosstab() 的第二个参数是可选的，但它决定了结果列的数量和顺序。如果省略，函数会按内层结果中首次出现的分类值动态推断列；但一旦内层某分类值没出现，对应列就为空，且无法控制列名。
- 显式提供第二参数更可靠，例如
'SELECT unnest(ARRAY[''A'',''B'',''C''])'或带ORDER BY的子查询 - 第二参数返回的值类型必须和内层第二列（
category）**完全一致**（包括大小写、空格），否则匹配失败，对应列全为 NULL - 如果第二参数返回 4 个值，而
AS ct(...)只定义了 3 个输出列，会报错return and sql tuple descriptions are incompatible
替代方案：不用 tablefunc 也能做行转列，但语法更啰嗦
当无法安装扩展（如共享主机、权限受限环境），可用标准 SQL 模拟：
- 用
MAX(CASE WHEN ... THEN value END)手动展开每一列，适合分类数固定且不多的场景 - 注意所有
value必须能参与聚合（如SUM、MAX），不能直接写CASE ... THEN col后裸露，否则会报错column must appear in the GROUP BY clause - 性能上，
crosstab()通常更快，因为它在 C 层实现；纯 SQL 方案在分类多、数据量大时会产生大量重复扫描
简单例子：
SELECT region, MAX(CASE WHEN product = 'Widget A' THEN sales END) AS "Widget A", MAX(CASE WHEN product = 'Widget B' THEN sales END) AS "Widget B" FROM sales GROUP BY region;
真正麻烦的不是语法，而是分类值本身不稳定——比如产品表每天新增，这时候硬编码列名或写死第二参数都会失效。得配合元数据查询动态生成 SQL，那已经超出 crosstab() 能力范围了。
