Re: SQL Property Graph Queries (SQL/PGQ)

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.

---
Cheers
Hannu

On Tue, Mar 24, 2026 at 2:05 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.
>
> 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