coalesce仅在array_agg结果为null时生效，即空结果集时；若聚合列全为null，则array_agg返回含null元素的数组，coalesce不触发。正确写法是coalesce(array_agg(col), '{}'::type[])。
COALESCE 不能直接“修复” ARRAY_AGG 的 NULL，得先理解它何时返回 NULL
当 ARRAY_AGG 作用于空结果集时（比如 WHERE 条件全不匹配），它返回的是 NULL，不是空数组 {}。这时候用 COALESCE(array_agg(...), '{}') 看似合理，但容易忽略一个关键点：如果聚合列本身允许 NULL，且所有行该列值都为 NULL，ARRAY_AGG 仍会返回非空数组（如 {NULL, NULL}），而 COALESCE 完全不介入——它只在最外层结果为 NULL 时才生效。
正确写法是 COALESCE 包裹整个 ARRAY_AGG 表达式，并指定空数组字面量
PostgreSQL 中空数组字面量必须带类型标注，否则 '{}' 会被当作未知类型，导致 COALESCE 类型推导失败：
SELECT COALESCE(ARRAY_AGG(name), '{}'::TEXT[]) FROM users WHERE id
<p>常见错误写法及后果：</p>
-
COALESCE(ARRAY_AGG(name), '{}')→ 报错：ERROR: could not determine polymorphic type because input has type unknown -
COALESCE(ARRAY_AGG(name), ARRAY[])→ 报错：ERROR: cannot determine type of empty array -
COALESCE(ARRAY_AGG(name), ARRAY[NULL])→ 返回{NULL}，不是空数组，语义错误
推荐写法（显式类型 + 安全）：
- 字符串数组：
COALESCE(ARRAY_AGG(col), '{}'::TEXT[]) - 整数数组：
COALESCE(ARRAY_AGG(id), '{}'::INT[]) - 若列类型复杂（如 JSONB），用
COALESCE(ARRAY_AGG(data), '{}'::JSONB[])
GROUP BY 场景下，空组需配合 FILTER 或子查询避免意外 NULL
当对主表 LEFT JOIN 后的从表字段做 ARRAY_AGG，空关联会导致该组 ARRAY_AGG 为 NULL。此时仅靠 COALESCE 不够，因为聚合发生在分组内，而空关联组本身是合法分组：
SELECT u.id, COALESCE(ARRAY_AGG(o.amount), '{}'::NUMERIC[])
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
GROUP BY u.id;
这段是对的，但要注意：
- 如果
orders表中某用户完全没有订单，o.amount在该组全为 NULL，ARRAY_AGG(o.amount)返回{NULL}（不是 NULL！），COALESCE 不触发 → 结果含{NULL}，可能不符合业务预期 - 想真正排除 NULL 元素，得加
FILTER (WHERE o.amount IS NOT NULL) - 或者改用
ARRAY_AGG(o.amount) FILTER (WHERE o.amount IS NOT NULL)，再套 COALESCE 处理空组
性能与可读性权衡：ARRAY_AGG + COALESCE 不会额外开销，但嵌套深了易出错
COALESCE 是简单运行时判断，对 ARRAY_AGG 结果做一次 NULL 检查，无性能隐患。但实际 SQL 中容易层层嵌套，比如：
COALESCE(ARRAY_AGG(COALESCE(name, 'N/A')), '{}'::TEXT[])
这种写法逻辑上没问题，但可读性差，且如果内层 COALESCE 导致全为 'N/A'，外层仍返回非空数组——和“空列表”需求可能脱节。更稳妥的做法是先明确业务定义：“空列表”是指无数据，还是指无有效数据？前者用外层 COALESCE，后者应在聚合前用 FILTER 或 WHERE 过滤。
最容易被忽略的是类型标注的强制性——哪怕你确定列类型是 TEXT，也必须写 ::TEXT[]，不然报错不提示具体原因，只说“type unknown”。
