On Wed, Mar 11, 2026 at 1:04 PM Ashutosh Bapat <[email protected]> wrote: > > There are two new patches 0004 and 0005 in the attached patchset. > Below is a description of those. > > All property reference and refactoring > -------------------------------------------------- > According to the SQL/PGQ standard, all properties reference > <variable>.* is allowed in COLUMNs, but it's not allowed anywhere else > e.g. in WHERE clause or buried inside a value expression. The current > error message is misleading in saying ""*" not allowed here". Instead > it should say "not supported" in COLUMNs and "not allowed" in other > places. Patch 0004 is the patch fixing the error message. It is not > accurate since it only checks whether <variable>.* appears in COLUMNs > clause or not. It doesn't differentiate between it appearing directly > in COLUMNs vs buried in another value expression. But I think it > serves the purpose for now. It's a limitation that we will eventually > remove. So it may be ok. > > I attempted to support it and turned out to be relatively simple. So > we can support it in the first version itself. However, the patch is > much larger. In order to expand all properties reference, we need to > find all the properties associated with the set of labels which > results from evaluating label expression. The properties are not > directly associated with a label, but through an element. Hence we > need to find at least one element associated with each label in the set. > Further the set of labels that an empty label expression results into > is all the labels which have at least one element of a given element > kind in the property graph. That's another reason why we want to find > at least one element associated with each of the labels. If we are > looking up element label catalog, why not to fetch all the elements > during transformation itself rather than waiting all the way till > the rewriting phase. So I changed the code to do that. And I think the > resultant code is much simpler, moves the error handling to > appropriate places and simplifies a lot of the rewriteGraphTable.c > code. Flip side is transform* functions are heavier, however in the > end it's code simplification. Since we are expanding the empty label > expression during transformation phase itself, we replace empty label > expression with a disjunction. But we need to know whether the > original label expression was empty or not in the ruleutils and when > consolidating path elements (generate_queries_for_path_pattern()). The > later usage will vanish once we support label disjunction. So I > introduced a flag to retain that status. All that refactoring is patch > 0005. > > Peter, if you think 0005 is larger to be acceptable at this stage, we > could revisit it later as well. > > In order to apply 0005, 0004 is needed even though 0005 nullifies that > change. I have separated 0004, so that those changes can be committed > even if we decide to postpone 0005. >
I have missed adding pg_node_attr(equal_ignore, query_jumble_ignore) to the three new fields in GraphLabelRef, since the equality of other fields is enough and those three fields don't need to be part of query jumbling. If a node with those fields populated is written ignoring those fields, what would resurrect those fields when read back? I don't think there is anything that would do it. So didn't add read_write_ignore. But I am not sure. List *properties pg_node_attr(equal_ignore, query_jumble_ignore); List *elements pg_node_attr(equal_ignore, query_jumble_ignore); List *elem_labels pg_node_attr(equal_ignore, query_jumble_ignore); -- Best Wishes, Ashutosh Bapat
