Snowflake中使用上条语句RESULT_SCAN的自动生成列是否有副作用？

在Snowflake里通过RESULT_SCAN搭配上条语句的query_id扫描结果集时，直接引用结果集里未显式加别名的自动生成列，不存在数据篡改类的隐式副作用，但会有很高的运行异常、逻辑错误风险，常见的问题包括这几类：

• 列名无感知失效
  Snowflake的自动列名完全绑定原始查询的表达式生成，只要原始查询的计算逻辑、写法有调整，自动列名就会同步变化。比如你一开始写SELECT COUNT(*) FROM user_orders，自动生成的列名是"COUNT(*)"，后面把语句改成统计去重用户数SELECT COUNT(DISTINCT user_id) FROM user_orders，列名就变成"COUNT(DISTINCT USER_ID)"，之前写死引用"COUNT(*)"的RESULT_SCAN语句会直接报列不存在的错误。
  如果原始查询是基于视图、动态SQL拼接生成的，哪怕你没动最终查询的代码，只要底层视图修改了字段、动态拼接逻辑发生变化，自动列名也可能无感知变更，往往到跑批报错时才会发现问题。
• 特殊字符引用写错直接触发逻辑bug
  自动生成的列名普遍包含括号、星号、空格、运算符这类特殊字符，引用时必须严格用双引号包裹，还要完全匹配大小写，只要写错了要么报语法错误，要么取数逻辑完全偏差。比如要读取上一条COUNT(*)的计算结果，必须写SELECT "COUNT(*)" FROM TABLE(RESULT_SCAN(LAST_QUERY_ID()))，要是漏写双引号直接写COUNT(*)，根本不是读取上一条的预计算结果，而是在RESULT_SCAN返回的结果上重新做计数，结果完全错误，这类问题隐蔽性极强，常规测试很容易漏过。
• 重名列直接触发执行冲突
  如果原始查询里有多个逻辑相近的计算列，自动生成的列名会出现重名。比如做多表关联时同时写两个COUNT(*)统计不同表的行数，结果集里会出现两个完全同名的"COUNT(*)"列，这时候在RESULT_SCAN里直接引用该列名，会直接报列歧义错误，语句无法正常执行。
• 跨版本、跨环境兼容问题
  存储过程、UDF返回的无别名结果列，在Snowflake版本迭代时可能调整默认命名规则；INSERT、UPDATE这类DML语句返回的系统统计列，在多语言部署环境下也可能出现命名差异，很容易出现本地调试正常，上线后版本升级、跨区域部署就突然运行失败的情况。

补充说明：RESULT_SCAN本身是直接读取服务端已经持久化的查询结果，不会对原始结果数据做任何修改，不存在数据写错、计算错误的隐式副作用，所有风险都集中在语句执行失败、取数逻辑偏差这类问题上。

规避方法 #

规则非常简单：只要是后续需要通过RESULT_SCAN引用的列，在原始查询里都显式加AS指定一个不带特殊字符的清晰别名，比如把SELECT COUNT(*) FROM user_orders改成SELECT COUNT(*) AS order_total_cnt FROM user_orders，后续扫描结果时直接引用order_total_cnt即可避开上述所有问题。

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