postgresql 16完全支持filter子句，无需额外配置；它必须紧跟聚合函数后写作agg() filter (where condition)，仅用于select或having中，不兼容窗口函数、嵌套或distinct，语义为行级过滤而非值映射。
PostgreSQL 16里FILTER能直接用，不用额外配置
PostgreSQL 16完全支持 FILTER 子句，它是标准 SQL:2003 的一部分，自 9.4 就已引入，16 版本没有任何降级或移除。只要不是极老的部署（比如还卡在 9.3 或更早），FILTER 就可用——它不是实验功能，也不依赖 GUC 参数开关。
FILTER必须跟在聚合函数后面，不能独立存在
FILTER 不是 WHERE 的替代品，也不能写在 GROUP BY 或 HAVING 里。它只能作为聚合函数的修饰子句，语法形如 COUNT(*) FILTER (WHERE status = 'active')。常见错误包括：
- 把
FILTER写在WHERE后面（报错：syntax error at or near "FILTER"） - 漏掉括号：写成
SUM(amount) FILTER WHERE paid（少(...)，会报错） - 在非聚合上下文中使用，比如
SELECT name FILTER (WHERE id > 10)（不合法，FILTER只属于聚合函数）
正确写法示例：
SELECT dept, COUNT(*) FILTER (WHERE salary > 8000) AS high_earners, AVG(salary) FILTER (WHERE hired_date >= '2022-01-01') AS avg_new_hire_salary FROM employees GROUP BY dept;
FILTER和CASE WHEN在语义和性能上并不等价
虽然 COUNT(*) FILTER (WHERE cond) 看起来等价于 COUNT(CASE WHEN cond THEN 1 END)，但二者有实质差异：
-
FILTER明确只影响该聚合的输入行集，不改变 NULL 处理逻辑；而CASE返回 NULL 时，多数聚合（如COUNT）会跳过它——表面结果常一致，但语义不同 -
FILTER在查询计划中通常生成更清晰的执行节点（Aggregate Filter），优化器更容易做谓词下推；CASE方式可能让统计信息失真，尤其涉及多层嵌套时 -
FILTER不支持ELSE分支，没法做“否则计为 0”这类逻辑；这时必须回退到CASE
例如想统计“满足条件则计 1，否则计 0”，FILTER 无法直接表达，得用：
COALESCE(COUNT(*) FILTER (WHERE status = 'done'), 0) + COALESCE(COUNT(*) FILTER (WHERE status != 'done'), 0)
不如直接写 SUM(CASE WHEN status = 'done' THEN 1 ELSE 0 END) 直观。
多个FILTER可共存，但不能嵌套或组合条件用OR/AND跨聚合
一个 SELECT 列表里可以有任意多个带 FILTER 的聚合，彼此完全独立：
SELECT COUNT(*) FILTER (WHERE score >= 90) AS a_count, COUNT(*) FILTER (WHERE score BETWEEN 80 AND 89) AS b_count, COUNT(*) FILTER (WHERE score <p>但要注意：</p>
- 不能在一个
FILTER里混用不同聚合逻辑，比如AVG(x) FILTER (WHERE ... OR SUM(y) > 100)——FILTER的WHERE部分只能是标量布尔表达式，不能含聚合 - 没有 “FILTER … ELSE …” 语法，也没有 “FILTER … AND FILTER …” 这种链式写法
- 如果条件本身依赖窗口函数或子查询结果，需确保其在当前聚合层级可见（通常需提前在 CTE 或子查询中算出）
真正容易被忽略的是：当 FILTER 条件里引用了未出现在 GROUP BY 中的非聚合列时，PostgreSQL 会报错——这和普通 WHERE 不同，FILTER 的谓词仍受 SQL 标准的分组约束。
