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

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