自定义SQL GROUPING_ROWS聚合函数语法合理性及优化问询

现有语法规则存在多处歧义，语法层面合理性不足，核心问题如下：

• 关键字定义模糊：语法规则中的SUBTOTAL[S]没有明确单复数是否都合法，也未说明属于可选还是必填关键字
• 符号用法冲突：冒号在常规SQL语法中多用于标识绑定变量，你设计的别名:表达式写法和现有SQL使用习惯冲突，容易导致解析歧义
• 规则与示例不匹配：给出的语法规则要求必须遵循field_name:expr结构，但示例中出现了COUNT(Units)、SUM(Units*1.2) withInflation这类没有前置别名+冒号的写法，规则无法覆盖示例场景
• 分隔符逻辑冲突：SQL标准中分号是语句结束标识，绝大多数SQL解析器遇到分号会直接终止语句解析，用分号做分组层级分隔符会和现有SQL语法体系产生严重冲突
• 返回结果规则缺失：示例中使用SELECT *返回结果，但没有定义如何区分原始明细行、不同分组层级的小计行，也没有说明小计行的非聚合字段取值规则

现有语法确实存在生硬、不符合SQL设计习惯的问题，除了上述的分号、冒号设计缺陷外，SUBTOTALS放在分组字段之后的写法不符合SQL「关键字在前、操作对象在后」的通用设计逻辑，自定义聚合的别名规则也和现有SQL的表达式 AS 别名习惯相反，用户学习成本较高。可行的优化方案如下：

• 替换冲突分隔符：删除分号分隔符，用小括号包裹每个分组维度的小计规则，多个分组维度之间用逗号分隔，完全兼容SQL现有分隔符规则，优化后结构示例：

SELECT * FROM table
GROUP BY GROUPING_ROWS (
  (Product SUBTOTALS SUM(Revenue) AS Revenue, SUM(Units) AS Units, COUNT(Units), SUM(Units*1.2) AS withInflation),
  (Year SUBTOTALS SUM(Revenue) AS Revenue)
)

• 对齐现有SQL习惯：把别名:聚合表达式的写法改为SQL通用的聚合表达式 AS 别名，不需要用户额外记忆新的别名规则，降低学习成本
• 调整关键字顺序：可选将SUBTOTALS调整到分组字段前面，更符合SQL的阅读习惯，例如写成(SUBTOTALS BY Product, SUM(Revenue) AS Revenue)，语义更清晰
• 补充内置标识函数：增加GROUPING_ROW_LEVEL()、GROUPING_ROW_FIELD()这类内置函数，方便用户直接获取当前行所属的分组层级、对应分组字段，不需要额外通过空值判断识别小计行

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