Re: SQL Property Graph Queries (SQL/PGQ)

From: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
To: assam258(at)gmail(dot)com
Cc: Alexander Lakhin <exclusion(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Amit Langote <amitlangote09(at)gmail(dot)com>, Junwang Zhao <zhjwpku(at)gmail(dot)com>, Vik Fearing <vik(at)postgresfriends(dot)org>, Ajay Pal <ajay(dot)pal(dot)k(at)gmail(dot)com>, Imran Zaheer <imran(dot)zhir(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SQL Property Graph Queries (SQL/PGQ)
Date: 2026-03-24 11:14:53
Message-ID: CAExHW5v58EJ0hVfQ-h3=q6DO-Emf_rxvqhU44GycjgL_j8PVJQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 24, 2026 at 6:35 AM Henson Choi <assam258(at)gmail(dot)com> wrote:
>
> Hi Ashutosh,
>
>> I have also added a few tests. I didn't add queries with all the
>> patterns you mentioned above. I tested a few by hand and all of them
>> worked as expected. Can you please check?
>
>
>
> I tested all the patterns and they all work correctly. No crashes,
> correct results.
>

Thanks a lot for the confirmation.

> One thing I noticed while reviewing the rewriter changes: the Assert
> at generate_queries_for_path_pattern() that checks alternating
> implicit/explicit elements doesn't actually work:
>
> #ifdef USE_ASSERT_CHECKING
> GraphElementPattern *prev_gep = NULL;
> #endif
> ...
> Assert(!prev_gep || prev_gep->implicit != gep->implicit);
>
> prev_gep is never updated in the loop -- it stays NULL throughout,
> so the Assert is always trivially true. It needs a
> "prev_gep = gep;" at the end of the loop body to actually perform
> the intended check.
>

Ah. Thanks for catching it. I think the Assertion is also not doing
what it mentions in the comment. It just checks whether the two
consecutive elements are not implicit ones; that doesn't necessarily
lead to an infinite or very long chain of implicit element patterns. I
have removed the assertion for now. We will add it if necessary, e.g.
when we start adding implicit edge patterns in which case the
possibility of long chains of implicit element patterns becomes real.

>>
>> Yes. That's a grammar issue. gram.y doesn't support it. Peter, do you
>> remember or know the reason why we don't support full edge left or
>> right? In fact, I am wondering what's the difference between full edge
>> left or right and full edge any direction?
>
>
>
> I looked into this. The lexer tokenizes "]->` as "]" + RIGHT_ARROW,
> so gram.y needs two alternatives -- just like the existing full edge
> right rule already does. The full edge left or right was simply
> missing both forms. Adding them fixes it:
>
> | '<' '-' '[' ... ']' '-' '>'
> | '<' '-' '[' ... ']' RIGHT_ARROW
>
> Per the standard, <-[]-> matches left or right direction while -[]-
> matches any direction. For simple directed graphs the results are
> the same, so EDGE_PATTERN_ANY seems like a reasonable mapping.

Our grammar is pretty tricky in this area especially because we can
treat a string of operators as a SQL operator. Peter may have
intentionally left it unsupported.

Here's the updated patchset.
--
Best Wishes,
Ashutosh Bapat

Attachment Content-Type Size
v20260324-0001-Cross-variable-references-in-graph-pattern.patch text/x-patch 4.4 KB
v20260324-0003-Cleanup-and-other-cosmetic-fixes.patch text/x-patch 6.2 KB
v20260324-0002-Implicit-vertex-patterns.patch text/x-patch 11.8 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Xuneng Zhou 2026-03-24 11:17:24 Re: log_checkpoints: count WAL segment creations from all processes
Previous Message John Naylor 2026-03-24 10:59:19 Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?