Hello, On Sat, Jul 15, 2023 at 4:43 AM Farias de Oliveira <matheusfarias...@gmail.com> wrote: > I believe I have found something interesting that might be the root of the > problem with RTEPermissionInfo. But I do not know how to fix it exactly. In > AGE's code, the execution of it goes through a function called > analyze_cypher_clause() which does the following: > > It ends up going inside other functions and changing it more a bit, but at > the end of one of these functions it assigns values to some members of the > query: > > query->targetList = lappend(query->targetList, tle); > query->rtable = pstate->p_rtable; > query->jointree = makeFromExpr(pstate->p_joinlist, NULL); > > I assume that here is missing the assignment of query->rteperminfos to be the > same as pstate->p_rteperminfos, but the pstate has the following values: > > {pstate = {parentParseState = 0x0, p_sourcetext = 0x2b06ef0 "MATCH (n) SET > n.i = 3", p_rtable = 0x2c6e590, > p_rteperminfos = 0x0, p_joinexprs = 0x0, p_nullingrels = 0x0, p_joinlist > = 0x2c6e678, p_namespace = 0x2c6e6c8, > p_lateral_active = false, p_ctenamespace = 0x0, p_future_ctes = 0x0, > p_parent_cte = 0x0, p_target_relation = 0x0, > p_target_nsitem = 0x0, p_is_insert = false, p_windowdefs = 0x0, > p_expr_kind = EXPR_KIND_NONE, p_next_resno = 3, > p_multiassign_exprs = 0x0, p_locking_clause = 0x0, p_locked_from_parent = > false, p_resolve_unknowns = true, > p_queryEnv = 0x0, p_hasAggs = false, p_hasWindowFuncs = false, > p_hasTargetSRFs = false, p_hasSubLinks = false, > p_hasModifyingCTE = false, p_last_srf = 0x0, p_pre_columnref_hook = 0x0, > p_post_columnref_hook = 0x0, > p_paramref_hook = 0x0, p_coerce_param_hook = 0x0, p_ref_hook_state = > 0x0}, graph_name = 0x2b06e50 "cypher_set", > graph_oid = 16942, params = 0x0, default_alias_num = 0, entities = > 0x2c6e228, property_constraint_quals = 0x0, > exprHasAgg = false, p_opt_match = false} > > So changing that won't solve the issue.
Does p_rtable in this last pstate contain any RTE_RELATION entries? If it does, p_rteperminfos being NIL looks like a bug in your code. Actually, given the back trace of the error that you shared, I am suspecting more of a problem in the code that generates a ResultRelInfo pointing at the wrong RTE via its ri_RangeTableIndex. That code should perhaps set the ri_RangeTableIndex to 0 if it doesn't know the actual existing RTE corresponding to that result relation. If you set it to some non-0 value, the RTE that it points to should satisfy invariants such as having the corresponding RTEPermissionInfo present in the rteperminfos list if necessary. -- Thanks, Amit Langote EDB: http://www.enterprisedb.com