Re: SQL Property Graph Queries (SQL/PGQ) - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: SQL Property Graph Queries (SQL/PGQ)
Date
Msg-id CAExHW5tB7LFTZ4EwZwo8grDC8CiBoLDv0VPwUSWDfTXJr84FQg@mail.gmail.com
Whole thread Raw
In response to Re: SQL Property Graph Queries (SQL/PGQ)  (Peter Eisentraut <peter@eisentraut.org>)
Responses Re: SQL Property Graph Queries (SQL/PGQ)
List pgsql-hackers
On Wed, Mar 25, 2026 at 2:27 PM Peter Eisentraut <peter@eisentraut.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



pgsql-hackers by date:

Previous
From: Andrey Borodin
Date:
Subject: Re: [PATCH] Add prepared_orphaned_transaction_timeout GUC
Next
From: Jim Jones
Date:
Subject: Re: COMMENTS are not being copied in CREATE TABLE LIKE