Commits on Aug 22, 2026
-
Empty label expression in view definition
A view definition depends on all the graph labels that are explicitly mentioned in the graph patterns in it so as to avoid it being rendered invalid when any of the labels is dropped. But when a view definition contains an empty label expression, we do not create any dependency between the view and the labels that the empty label expression resolves to. Resolve an empty label expression during transformation phase so that we can create dependency between those labels and the view. This will further help to avoid invalidation of a view containing all-properties references when we support it. An empty label expression may resolve to an empty set of labels if there are not labels associated with the elements matching the kind of element pattern containing the label expression. We do not have a syntax level support for a label expression containing no labels. Hence we can not dump a view containing such an empty label expression. Throw an error when a query contains such an empty label expression. There are possibly no real usecases which use such queries. Author: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> Discussion: https://www.postgresql.org/message-id/CAExHW5twGP5Zuk4Zch4kz8XDrSpckWQipMs=ysAj8GmqNa2FCQ@mail.gmail.com
authored and Commitfest Bot committed
Aug 22, 2026 -
View referencing labels shared by vertex and edge tables
While at it add a test for view containing labels which are shared by both vertex and edge tables. When such a label is dropped from only vertex tables or only edge tables, the view may be rendered invalid because properties only associated with that label can not be resolved. The fix will need to wait for the SQL/PGQ standard to specify the behaviour in such a case. Author: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
AyoubKaz07 authored and Commitfest Bot committed
Aug 22, 2026 -
Support all properties reference in COLUMNs list of a GraphTableRef
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 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 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 to 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 expresison 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. While at it also fix a test to use correct property name so that it throws expected error. Before this change, the properties of a given element were resolved after the element patterns with the same variable name were squashed. With this change the order is reversed. Author: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> Reported by: Henson Choi, Junwang Zhao
AyoubKaz07 authored and Commitfest Bot committed
Aug 22, 2026 -
Add support for label conjunction (&) in SQL/PGQ
The SQL/PGQ standard allows label expressions to use boolean operators, such as conjunction of labels: MATCH (a IS label1 & label2). Previously, only disjunction (|) was supported in graph element patterns. This commit adds support for implicit label conjunction: a path factor appearing with different label expressions in multiple graph element patterns, which needs to be conjucted as if it was written with an explicit "&" which is not yet supported in grammar. Author: Ayoub Kazar <ayoub.kazar@data-bene.io>
AyoubKaz07 authored and Commitfest Bot committed
Aug 22, 2026
