| From: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
|---|---|
| To: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
| Cc: | assam258(at)gmail(dot)com, Alexander Lakhin <exclusion(at)gmail(dot)com>, 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-25 09:12:18 |
| Message-ID: | CAExHW5tB7LFTZ4EwZwo8grDC8CiBoLDv0VPwUSWDfTXJr84FQg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Mar 25, 2026 at 2:27 PM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>
> On 23.03.26 16:00, Ashutosh Bapat wrote:
> > An empty pattern has no label expression which is equivalent to
> > disjunction of all applicable labels. If we add an empty pattern in
> > the rewrite phase, we will require its label expression to be resolved
> > in the rewrite phase. Looking at the proposed changes for all
> > properties reference [1], I am moving towards resolving the label
> > expression in the transformation stage itself. So I think it's better
> > to add the implicit vertex patterns during the transformation stage to
> > be future proof. Rewriter should just then rewrite the patterns into
> > joins and unions. Your point is correct that the implicit vertex
> > should not be visible in view definition or deparsed query. For that I
> > have added a flag implicit to GraphElementPattern.
> > GraphElementPatterns with implicit = true are ignored by ruleutils.
> > Implemented it that way in the attached patch.
> >
> > Vertex patterns without an edge pattern in between are not supported
> > OTOH. Added an ereport for the same.
> >
> > 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?
>
> This functionality that you can leave off empty vertex patterns at the
> beginning and end is part of the optional feature G047, which we don't
> claim to support. So we should reject these path patterns.
>
Thanks for the clarification. What about the implicit empty vertex
patterns in the middle of the path? Should we reject these path
patterns also?
> >> Separately, while testing various edge patterns I noticed that
> >> `<-[]->` (full edge left or right) produces a syntax error:
> >>
> >> SELECT count(*) FROM GRAPH_TABLE (g1 MATCH ()<-[]->() COLUMNS (1 AS one));
> >> ERROR: syntax error at or near "->"
> >>
> >> Per the standard BNF, this should be valid:
> >>
> >> <full edge left or right> ::=
> >> <left arrow bracket> <element pattern filler> <bracket right arrow>
> >>
> >> i.e., `<-[]->` = `<-[` + `]->`. This is a separate parser issue,
> >> not related to the implicit vertex insertion above.
> >
> > 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?
>
> <full edge left or right> is part of optional feature G043, which we
> don't claim to support.
>
Ok.
--
Best Wishes,
Ashutosh Bapat
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim Jones | 2026-03-25 09:21:56 | Re: COMMENTS are not being copied in CREATE TABLE LIKE |
| Previous Message | Andrey Borodin | 2026-03-25 09:06:22 | Re: [PATCH] Add prepared_orphaned_transaction_timeout GUC |