PostgreSQL 11中WINDOW子句必须紧跟FROM之后、WHERE之前，且仅出现一次；正确写法为SELECT SUM(x) OVER w FROM t WINDOW w AS (PARTITION BY dept ORDER BY date)，错误写法是将其置于SELECT后导致语法报错。
PostgreSQL 11 中 WINDOW 子句的正确写法
PostgreSQL 11 支持 WINDOW 子句，但它不是独立语句，也不能放在 SELECT 之后任意位置——必须紧跟在 FROM 子句之后、WHERE 之前，且只能出现一次。
常见错误是把它当成语法糖直接塞进 SELECT 列表里，比如写成 SELECT sum(x) OVER w WINDOW w AS (ORDER BY id)，这会报错：ERROR: syntax error at or near "WINDOW"，因为 WINDOW 子句不能和 OVER 写在同一行还省略位置约束。
-
WINDOW子句定义的是命名窗口，后续所有OVER w都复用它，不是为单个函数临时声明 - 窗口名（如
w）作用域仅限当前查询，不能跨查询复用 - 定义中不能引用列别名，只能用原始列名或表达式（如
ORDER BY created_at DESC）
复用窗口时 ORDER BY 和 PARTITION BY 的陷阱
一旦用 WINDOW w AS (PARTITION BY category ORDER BY score DESC) 定义好窗口，所有 OVER w 都强制继承这个排序和分组逻辑。如果某个聚合函数（比如 count(*)）不需要排序，但你又用了 OVER w，PostgreSQL 仍会执行排序——带来不必要的开销。
更隐蔽的问题是：如果某列在 PARTITION BY 中被隐式转换（比如 category::text），而你在 SELECT 中用的是原列 category，类型不一致会导致窗口定义失效或报错 column "category" does not exist in window specification。
- 确保
PARTITION BY和ORDER BY中的表达式与表结构严格一致，避免隐式类型转换 - 若需不同排序逻辑，必须另起一个窗口名，比如
WINDOW w1 AS (...), w2 AS (...) - 注意
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW这类帧子句也属于窗口定义的一部分，复用时一并继承
和子查询 / CTE 对比：什么时候该用 WINDOW 子句？
有人试图用 CTE 预先计算窗口函数结果来“复用”，比如先算好 row_number() OVER (PARTITION BY x ORDER BY y)，再在主查询里引用。这看似复用，实则多了一层物化，性能反而差；而 WINDOW 子句只是语法复用，执行计划里仍是单次扫描+一次窗口计算。
典型适用场景是多个函数依赖同一窗口逻辑：比如同时需要 rank()、avg() OVER ()、first_value() OVER ()。这时写成 WINDOW w AS (PARTITION BY dept ORDER BY salary)，然后 rank() OVER w、avg(salary) OVER w，比重复写三遍窗口定义清晰且安全。
- CTE 适合逻辑拆解或中间结果重用（如过滤后数据集），不适合替代窗口定义复用
-
WINDOW子句不改变执行计划，只是减少重复输入和出错概率 - 如果窗口定义本身很短（比如只有
ORDER BY id），硬套WINDOW反而增加阅读成本
PostgreSQL 11 的兼容性边界
PostgreSQL 11 是第一个支持 WINDOW 子句的版本，但不支持在视图定义里使用它——视图 DDL 中写 WINDOW 会报错 WINDOW clause is not allowed in view definition。想在视图里复用窗口？得把完整 OVER (...) 写进去，或者改用函数封装。
另一个限制：不能在 HAVING 或 GROUP BY 中引用窗口函数，哪怕用了 WINDOW 子句也不行。窗口函数只允许出现在 SELECT 列表和 ORDER BY 中。
- 升级到 12+ 也没放宽这些限制，
WINDOW子句行为基本保持稳定 - 嵌套查询中，外层查询无法引用内层的
WINDOW定义，每个查询必须独立声明 - 如果迁移旧 SQL，注意检查是否误把
WINDOW当作 PostgreSQL 10 或更早版本的特性来用——那会直接语法报错
