> The assertion itself is correct — transformGraphTablePropertyRef() should
> never create a GraphPropertyRef for a variable not present in the path
> pattern. The real problem is that the element's WHERE clause was only
> receiving its own mapping instead of all mappings in the path pattern.
>
> In generate_query_for_graph_path():
>
> tr = replace_property_refs(rte->relid, pf->whereClause, list_make1(pe));
>
> list_make1(pe) passes only the current element's mapping to
> replace_property_refs_mutator(). When the element WHERE clause references
> another variable (e.g., `b.name != a.name` inside the `b` element pattern),
> the mutator cannot find `a` in the mappings list, leaving found_mapping
> NULL.
>
> Note that the graph pattern-level WHERE clause already passes
> graph_path (the full mapping list), which is why the same condition works
> when placed outside the element pattern.
>
> The fix is simply:
>
> tr = replace_property_refs(rte->relid, pf->whereClause, graph_path);
>
> Ashutosh, could you include this fix in the next patch revision?
>
> With this fix, the reported query runs without crash and returns the
> correct result. The graph_table regression test also passes cleanly.
>
> Also, I'd like to check — do you see any potential side effects from
> passing the full graph_path instead of list_make1(pe)? Since the mutator
> now has access to all element mappings, I want to make sure there are no
> unintended interactions in other code paths.
Hi Henson,
Thank you so much for resolving the issue so quickly.
I'm a beginner in SQL/PGQ and was unsure if my syntax was compliant with standards.
I might have misunderstood at the time. I thought that if it wasn't compliant,
changing the assertion to throw an error message would be the simplest fix.
I subsequently modified and tested it according to your suggestions, and the results were correct.
--
regards,
Man Zeng
