Re: Add support for label conjunction (&) in SQL/PGQ

Hello Ashutosh,

Thanks for the review.

On 30/07/2026 09:20, Ashutosh Bapat wrote:
> Hi Ayoub,
>
> Thanks for your interest in SQL/PGQ.
>
> On Wed, Jul 22, 2026 at 3:02 PM <ayoub(dot)kazar(at)data-bene(dot)io> 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-RPJR5A@mail.gmail.com
>
> --
> Best Wishes,
> Ashutosh Bapat

I managed to rebase your previous patches that you referenced, then on
top of them i added the implicit label conjunction, the explicit case
can be left for later since its requires just grammar change (having
both at the same time is very good for expressiveness).

I noticed a small issue in your
v20260318-0001-Support-all-properties-reference-in-COLUMN.patch

-  BoolExpr   *be = castNode(BoolExpr, labelexpr);
+  BoolExpr   *be = castNode(BoolExpr, pf->labelexpr);

this would break the recursion since its always getting the top level
expression i guess ?

Attached are all 3 rebased patches on top of each other as you suggested
+ the label conjunction patch on top of them.

Regards,

Ayoub Kazar