42803 — 分组错误（grouping_error）

速览

42803 是 grouping_error（分组错误）：分组查询输出了既未分组也未聚合的值。本案例只按 category 分组，却选择 label。

含义

分析器必须为每个分组的每个选择表达式确定一个值。固定报文为 column "%s.%s" must appear in the GROUP BY clause or be used in an aggregate function。已检查的 check_functional_grouping 路径要求 GROUP BY 列包含该表主键的全部列，才会认可函数依赖；不能把任意看似唯一的表达式都当作例外。本案例的 VALUES 关系没有这种表约束，因此加入 label 会把结果粒度从每个 category 一行明确改成每个 (category,label) 一行，而不是语义中性的修复；自动提交错误后为 IDLE。

诊断

检查 SELECT、HAVING 及相关排序表达式中的非聚合项。依赖函数依赖前先核对关系约束，修改 GROUP BY 前先决定期望每个 category 一行，还是每个 category/label 一行。ordered-set 聚合的 direct argument 还有单独的分组列规则；下方记录其源码 DETAIL，但它不是本案例的普通分组查询。

处理

把需要保持的表达式加入 GROUP BY，或用明确规则聚合，再核对行数。案例按 category,label 修复并返回两行，因为两个 label 形成两个组；如果业务结果应每个 category 一行，就要选择聚合或明确保留哪个 label。显式事务中失败语句会使事务进入 INERROR，应先回滚或回到合适的 savepoint；本案例的自动提交路径才会回到 IDLE。

实测诊断

固定 parse_agg.c 组是 ERROR。本案例主报文为 column "%s.%s" must appear in the GROUP BY clause or be used in an aggregate function。当未分组变量是 ordered-set 聚合的 direct argument 时，同一源码分支在 context->in_agg_direct_args 守卫下追加仅源码确认的 DETAIL：Direct arguments of an ordered-set aggregate must use only grouped columns.；本案例普通分组查询没有产生该 DETAIL。

代表案例

注册表用两个 (category,label) 值，只按 category 触发，再按 category,label 排序修复并断言 (1,a,1)、(1,b,1)。

SELECT category, label, count(*) FROM (VALUES (1, 'a'), (1, 'b')) AS grouping_rows(category, label) GROUP BY category;
SELECT category, label, count(*) FROM (VALUES (1, 'a'), (1, 'b')) AS grouping_rows(category, label) GROUP BY category, label ORDER BY category, label;

选定的 18.6 与 10.21 运行均通过 SQLSTATE、严重级别、状态/恢复、修复、清理和一次性实例停止断言。详见 案例 JSON 与 作者证据；私有清单和注册表哈希也记录在其中。

版本

锁定目录从 7.4 存在边界起包含该条件并列出相关快照。选定自然案例已在 PostgreSQL 18.6 与 10.21 通过；这是有界观察，不能推断所有中间版本或所有源码分支。

相关

• 42804
• 42703

来源

• src.errcodes.REL_18_6 — fixed definition at 724edf9bde9d356724ad384a2e196edc3c9f80f7; SHA-256 6e8de346643ba84aa3c9c6a73360acfc7b2dfb89162c06c08ce9bf5bcd5bbcba (source).
• src.grouping-error.18.6 — src/backend/parser/parse_agg.c lines 1552–1558 at 724edf9bde9d356724ad384a2e196edc3c9f80f7; blob SHA-256 6e80a805fddbfc9c7e0f3047b348bf992a20c99f16ce7fee89c7067753027f72 (source).
• src.grouping-error.10.23 — src/backend/parser/parse_agg.c lines 1356–1362 at 02991e79f8f58bc208f05dcc8af0c62dbe0a6ea4; blob SHA-256 4c7e12bba2ffd465eb55d22c2adc593afa97e5a5f9a93045a882afab1401cb28 (source).
• src.grouping-functional-dependency.18.6 — src/backend/catalog/pg_constraint.c lines 1728–1778 at 724edf9bde9d356724ad384a2e196edc3c9f80f7; blob SHA-256 0aa324acd355da955f8eb6cec17f1a0138277a8bebd2c6e999cd2a603d3bfa01 (source).
• src.grouping-functional-dependency.10.23 — src/backend/catalog/pg_constraint.c lines 1057–1107 at 02991e79f8f58bc208f05dcc8af0c62dbe0a6ea4; blob SHA-256 c90dff2d1d863e6b43102d762cec6e08b6c4ba40458045b525a14b49865d8a65 (source).
• src.calls.REL_18_6 / src.calls.REL_10_23 — fixed call scans, SHA-256 9ee8a0e81d8f0825c5c1ae45583439859a26e602bdd4ce2f2a62aa278867ccbf / 00d16d3eb01b71ccf1b245c8f3102f9d0ec9f36fb02777b8dd1b99fcb263040c.
• manifest.42803 / snippet-registry.42803 — hashes are recorded in evidence/42803.json and each runtime record.