Hi, On Fri, 18 Sept 2026 at 06:22, Richard Guo <[email protected]> wrote: > > Further fuzzing with Claude on the join alias found this bug. The > following queries fail in various ways on master and all supported > branches: > > create table t (a int, b int); > > select 1 from ((select (select 1) as x) s cross join t) j > where (select 1 where j is null) is null; > ERROR: cannot handle unplanned sub-select > > select 1 from ((select (select 1) as x) s cross join t) j > where (1, 1) in (select (j is null)::int, count(*) from t); > TRAP: failed Assert("!IsA(node, SubLink)"), File: "prepagg.c" > > select 1 from ((select (select 1) as x) s cross join t) j > where exists (select 1 from t tablesample system ((j is null)::int * 100)); > ERROR: unrecognized node type: 22 > > Once subquery s is flattened, the joinaliasvars entry for j.x is no > longer a Var but the SubLink (select 1), so expanding a reference to j > inside a sub-select inserts a SubLink into that sub-select. > > But flatten_join_alias_vars_mutator fails to notice this and thus does > not set the sub-select's hasSubLinks flag. So preprocess_expression > skips SS_process_sublinks, and the SubLink survives into code that > can't cope with one. > > The fix is to make the same checkExprHasSubLink() test in the > whole-row path. See attached.
This looks reasonable to me. I can see how the recursive call might look sufficient here, but once the alias entry already contains a SubLink, there needn't be another join Var to expand and trigger the check. Handling it like the single-column case seems a good fit. Patch LGTM. Regards, Ayush
