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

On Tue, Mar 24, 2026 at 6:54 PM Hannu Krosing <hannuk@google.com> wrote:
>
> Hallo Everyone!
>
> Good to see this progressing rapidly.
>
> I did not see much documentation committed yet, so I am asking here.
>
> What is the best way to find out which parts of the SQL/PGQ standard
> we aim to implement for v19 and what are the know limitations?
>
>
> The reason I'm asking is that the first thing I tried with fresh
> checkout was a minimally modified sample from
> https://duckpgq.org/documentation/sql_pgq/ and it immediately failed
>
> ------8<------------8<------------8<------------8<------------8<------------8<------------8<------
> =# CREATE TABLE person(id serial primary key, name text);
> CREATE TABLE
>
> =# CREATE TABLE person_knows_person(
>     person1id int  REFERENCES person ( id ),
>     person2id int  REFERENCES person ( id )
> );
> CREATE TABLE
>
> =# CREATE PROPERTY GRAPH snb
> VERTEX TABLES (
>     Person
>   )
> EDGE TABLES (
>     Person_knows_person
>         SOURCE KEY ( person1id ) REFERENCES Person ( id )
>         DESTINATION KEY ( person2id ) REFERENCES Person ( id )
>         LABEL Knows
>   );
> ERROR:  42P17: no key specified and no suitable primary key exists for
> definition of element "person_knows_person"
> LINE 6:     Person_knows_person
>             ^
> LOCATION:  propgraph_element_get_key, propgraphcmds.c:334
> Time: 0.459 ms
> ------8<------------8<------------8<------------8<------------8<------------8<------------8<------
>
> It worked when I changed person_knows_person.person1id into PRIMARY KEY.

Yes, each element is expected to have a key, either defined explicitly
when creating the graph or implicitly via its primary key.

I'm not sure whether we should infer the key from the source and
destination keys, though it's doable.

see https://www.postgresql.org/docs/devel/catalog-pg-propgraph-element.html

>
> ---
> Cheers
> Hannu
>
>
> On Tue, Mar 24, 2026 at 2:05 AM Henson Choi <assam258@gmail.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.
> >
> > 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.
> >
> >>
> >> 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.
> >
> > Regards,
> > Henson



--
Regards
Junwang Zhao