PostgreSQL直接查询视图与CTE查询视图返回结果行数不一致问题

1. PostgreSQL CTE的优化栅栏特性：
   PostgreSQL 11及更早版本中，CTE默认是优化栅栏，外层查询的过滤条件不会下推到CTE内部，会先完整执行CTE的逻辑生成全量结果后再过滤；而直接查询视图时，优化器会将外层过滤条件下推到视图的基表层面提前过滤。如果你的视图依赖的对象存在非稳定逻辑，两种执行方式的结果就会出现差异。
   PostgreSQL 12及以上版本虽然支持CTE展开，但因为你用到的自定义函数fnc_getname声明为VOLATILE类型，优化器会认为该函数存在副作用，因此依然会强制将CTE结果物化，不会下推外层过滤条件，和旧版本行为一致。

2. 行级安全（RLS）策略的影响：
   如果视图依赖的任意基表（包括t_name、v_kokyaku关联的基表等）开启了行级安全，且RLS策略中使用了非稳定的判断逻辑（比如依赖VOLATILE函数、当前会话状态等），那么过滤条件下推（直接查询）和先全量扫描再过滤（CTE方式）两种场景下，RLS的执行时机和判断结果可能出现差异，最终导致返回的行数不一致。

3. 自定义函数的非稳定性：
   你用到的fnc_getname被声明为VOLATILE，允许相同输入参数在同一个事务的不同调用中返回不同结果。如果t_name表的数据在查询过程中发生了变化，或者RLS对t_name的访问限制逻辑非稳定，也会间接导致视图返回的行集合出现差异。

• 确认PostgreSQL版本，执行SELECT version();即可查看，先明确CTE的默认行为逻辑。
• 检查所有基表和依赖视图是否开启了行级安全，执行：

SELECT relname, rowsecurity FROM pg_class 
WHERE relname IN ('t_anken', 't_gyomu', 't_kokyaku', 't_kotei', 'employee', 't_anken_jyuchu', 't_name');

查看返回结果中rowsecurity为true的表，进一步检查对应表的RLS策略逻辑。

• 对比两次查询的执行计划，分别执行以下语句获取实际执行计划，确认过滤条件的执行位置、JOIN顺序、是否存在RLS相关执行节点的差异：

-- 直接查询的执行计划
EXPLAIN ANALYZE select * from v_anken where gyomu_name like '%ひとり%' and nyuryoku_cd like '0187';
-- CTE查询的执行计划
EXPLAIN ANALYZE with tempt as (select * from v_anken ) select * from tempt where gyomu_name like '%ひとり%' and nyuryoku_cd like '0187';

• 验证函数稳定性的影响：如果fnc_getname的逻辑确实是相同输入永远返回相同结果，可以临时将函数修改为IMMUTABLE类型，再执行两次查询看结果是否一致，若一致则可确认是函数稳定性标记导致的优化行为差异。
• 排除并发修改影响：将事务隔离级别调整为可重复读，在同一个事务中先后执行两次查询，若结果依然不一致则可排除中间数据被其他事务修改的可能。

内容的提问来源于stack exchange，提问作者Nguyễn Thắng