Re: SQL Property Graph Queries (SQL/PGQ)

Hi Henson,

Thanks a lot for your interest in SQL/PGQ patches. Your expertise will
certainly help.

On Fri, Dec 26, 2025 at 6:03 PM Henson Choi <assam258@gmail.com> wrote:
>
> Following up on my Dec 24 email - three features completed:
>
> 1. LABELS() function
>    - Returns text[] of element labels
>    - Fixed privilege checking from previous version
>    - Enables optimizer pushdown for branch pruning
>
> 2. PROPERTY_NAMES() function
>    - Returns text[] of property names
>    - Similar approach to LABELS()
>

I could not find specification of these functions in SQL/PGQ standard.
It's a large document and I might be missing something. Can you please
point me to the relevant sections?

While there's a distinction between structured (SQL/PGQ) and semi-structured
(Cypher) query models, I don't think we need to strictly exclude
semi-structured patterns that work well within the structured framework.
Whether this should be proposed as a future SQL/PGQ standard extension or
remain a PostgreSQL-specific extension is worth discussion. Given the
practical utility demonstrated in graph query deployments, there might be
value in standardizing such introspection functions.

Similarly, I'd suggest considering Cypher's SHORTEST PATH for future
SQL/PGQ standards. If we treat SHORTEST PATH as a specialized join type
in SQL and handle it through query rewrite, PostgreSQL's existing planner
infrastructure could support it efficiently. This approach has been proven
in practice and could be a valuable addition to the next standard revision.

> 3. Multiple path patterns
>    - Syntax: MATCH (a)->(b), (b)->(c)
>    - Implements SQL/PGQ standard feature (was TODO)
>

This path pattern list feature is discussed in section 10.4 of the
standard. I think supporting this feature would be a good addition to
SQL/PGQ compliance. The current patchset is already large. I (and
AFAIK Peter as well) am focusing on getting that patchset in a
committable shape. Once committed, it will facilitate adding features
like path pattern list, quantified path patterns, label conjunction
etc. as incremental relatively smaller commits.

Since you could build one of the complex features without changing a
lot of earlier implementation, it validates that the basic
implementation is extensible and yet robust. Thanks for that
validation.

The way you have implemented it, it can lead to a path pattern with
two vertex patterns next to each other without an interleaving edge
pattern. That would throw an error or assertion. If you try path
patterns without a common vertex, you will get that error. That is not
covered by your tests. In such cases, the paths should end up being
full-joined rather than concatenated. I don't see it being implemented
that way. I think more work is needed here.

You're absolutely right, and I apologize for the hasty implementation.

I agree that merging this after the current commitfest makes more sense -
it keeps the core patchset focused and reviewable. I'll rework this
properly with correct handling for disjoint patterns and full join logic.

Having more people who can maintain and extend SQL/PGQ reduces the
risk for both the community and PostgreSQL itself. When I have a revised
version ready, would you be willing to review it again?

[1] https://www.postgresql.org/message-id/CAExHW5sr+dJPCFw2OqXUfPPqPks8qmsivaAYhRiBdFANcX8RHw@mail.gmail.com

--
Best Wishes,
Ashutosh Bapat

Best regards,