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 <[email protected]> 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
