PostgreSQL 10 OLAP中ROWS 2 FOLLOWING报错问题及修正咨询

我来帮你理清这个问题——在PostgreSQL 10的OLAP分析里碰到这种窗口函数的语法差异，其实是个版本特定的语法限制小坑。

问题原因 #

PostgreSQL 10对窗口框架的单一边界语法有严格要求：

• 当你使用ROWS n PRECEDING或者UNBOUNDED PRECEDING时，系统会默认把CURRENT ROW作为框架的结束边界，所以单独写rows 2 preceding是合法的，等价于rows between 2 preceding and current row。
• 但单独使用ROWS n FOLLOWING是不允许的，因为系统无法推断框架的起始边界（没有合理的默认值）。而rows between 2 preceding and 2 following是完整的边界定义，自然能正常运行。

简单说就是：PostgreSQL 10只允许以PRECEDING结尾的单一边界写法，FOLLOWING必须搭配明确的起始边界一起使用。

修复方案 #

要正确使用rows 2 following，你需要明确写出完整的窗口框架范围，根据你的业务需求选择对应的写法：

场景1：计算当前行 + 后续2行的聚合值

把原来的ROWS 2 FOLLOWING替换为完整的边界定义：

SELECT 
  your_column,
  SUM(your_column) OVER (
    ORDER BY sort_column 
    ROWS BETWEEN CURRENT ROW AND 2 FOLLOWING
  ) AS rolling_sum
FROM your_olap_table;

场景2：计算从第一行到当前行后续2行的聚合值

如果需要覆盖更早的行，起始边界设为UNBOUNDED PRECEDING：

SELECT 
  your_column,
  SUM(your_column) OVER (
    ORDER BY sort_column 
    ROWS BETWEEN UNBOUNDED PRECEDING AND 2 FOLLOWING
  ) AS rolling_sum
FROM your_olap_table;

额外说明 #

这个语法限制在PostgreSQL 11及之后的版本中已经被移除了——升级到更高版本后，单独写ROWS 2 FOLLOWING会被自动解析为ROWS BETWEEN CURRENT ROW AND 2 FOLLOWING，无需手动补充边界。如果你的环境允许升级，这也是一劳永逸的解决办法。

内容的提问来源于stack exchange，提问作者Ken Moore