Hi Ayoub, Thanks for your interest in SQL/PGQ.
On Wed, Jul 22, 2026 at 3:02 PM <[email protected]> wrote: > Hello everyone, > > I'm proposing a patch that adds support for label conjunction in > SQL/PGQ, i'll quote from the commit message since its already a > semi-complete description: > > 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. > > As your patch does, the label conjunction requires changes to the grammar. We need to be careful there. But we can support conjunction without requiring a change to the grammar - by allowing multiple element patterns with non-empty label expression to share the same variable name. I would start with that. You have mentioned that your patch supports it. So, let's create two patches - one without grammar and other with grammar. The first one by itself has higher chances of getting committed. Oracle also does not seem to support explicit label disjunction. I would also question whether label conjunction is a feature required by the field just so that we prioritize the features by field demand. > Supporting label conjunction, disjunction and in the future ; label > negation, requires an evaluation of a full label expression. Previously > get_path_elements_for_path_factor() considered only flat BoolExpr > evaluation (as it only knew about disjunctions). > > As required, this commit adds a recursive label expression evaluator, > get_path_elements_for_path_factor() now fetches all candidate table > elements for the path factor kind once and evaluates each table > element's label OIDs against the label expression tree. > > I'm not sure if the current approach of getting all elements and then > iteratively pulling their corresponding labels from catalog ; which > might seem costly (if doing many `table_open`s every time is a lot and > pg_propgraph_element is large enough), we can change it to keep > `pg_propgraph_element_label` open until all element OIDs are treated. > I think the way label are resolved into elements works only for disjunction, conjunction and negation require some refactoring. I would suggest taking patches from [1], rebasing all properties supporting patch from [2] on top of those patches. Implement implicit label conjunction on top of these patches. I am hoping that patches from [1] would get committed to PG 19 - hence those are separate patches. For PG 20, we may decide to distribute the code slightly differently across the patches. [1] https://www.postgresql.org/message-id/CAExHW5uNRS9tcgnHCc03rh5oQhFPz-wrC1YF%2B_XUhPdwK2fbXw%40mail.gmail.com [2] https://www.postgresql.org/message-id/caexhw5tyce9qycvvrakueeskw5rtr+mrzsg3u64qsps-rpj...@mail.gmail.com -- Best Wishes, Ashutosh Bapat
