Snowflake连接视图时Where子句过滤失效引发类型转换错误咨询

问题重现 #

以下是简化后的故障场景（基于Snowflake语法）：

create or replace table SRC (DTM varchar);
insert into SRC values ('2020-01-01'),('00-00-00');

create or replace view SRC_V as 
(
    select DTM::timestamp as DTM 
    from SRC where DTM!='00-00-00'
);

-- 执行此语句报错：Timestamp '00-00-00' is not recognized
select * from
SRC_V as a 
inner join SRC_V as b
ON a.DTM = b.DTM;

单独查询SRC_V时能正常返回有效数据，但连接时却因无效记录的类型转换失败报错，同时存在以下特殊现象：

• 用CTE包裹视图后连接可正常执行：

with x as (select DTM from SRC_V)
select * from
x as a 
inner join x as b
ON a.DTM = b.DTM;

• FULL OUTER JOIN可正常运行，但LEFT/RIGHT OUTER JOIN仍会报错。

核心原因：查询优化器的执行顺序重写 #

这是Snowflake查询优化器的设计行为，而非Bug。视图定义里的逻辑顺序（先过滤无效值再转换类型）并不一定会被严格执行——优化器会基于成本、执行效率等因素重写查询计划，可能将类型转换操作提前到过滤逻辑之前执行。

当执行视图连接时，优化器可能会将视图的逻辑“展开”，直接对源表SRC进行转换和连接操作，此时无效值'00-00-00'会被尝试转换为timestamp，导致报错。而SQL Server的查询优化器在处理视图时，会更倾向于保留视图内的执行顺序，因此不会出现该问题。

特殊现象的解释 #

• CTE写法有效：CTE在该场景下会被优化器视为“物化”操作——先执行视图的过滤和转换，将结果暂存后再进行连接，避免了重新访问源表时的提前转换。
• FULL OUTER JOIN正常、LEFT/RIGHT JOIN失败：不同连接类型的执行路径不同，FULL OUTER JOIN的执行逻辑会促使优化器先完成视图的过滤和转换步骤；而LEFT/RIGHT JOIN的优化策略仍会选择直接操作源表，导致提前触发无效值的类型转换。

可行的临时解决方案 #

由于无法修改视图且连接代码由生成器生成，可通过以下方式规避：

1. 用CTE或子查询预先获取视图的结果集，再进行连接（如示例中的CTE写法）；
2. 在查询中显式使用TRY_CAST/TRY_CONVERT包裹视图字段（若生成器支持自定义字段处理），避免转换失败终止查询：

select * from
(select TRY_CAST(DTM as timestamp) as DTM from SRC_V) as a 
inner join (select TRY_CAST(DTM as timestamp) as DTM from SRC_V) as b
ON a.DTM = b.DTM;

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