| 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 |
| 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? |