Hi all,
I've been writing a hands-on PostgreSQL book [1] and put together a chapter on the new SQL/PGQ support (CREATE PROPERTY GRAPH / GRAPH_TABLE) in PostgreSQL 19. CREATE PROPERTY GRAPH and fixed-depth GRAPH_TABLE pattern matching both work well and are a genuine readability win over the equivalent self-joins. One thing stood out enough that I wanted to ask rather than just assume it's unfinished: quantified (variable-length) path patterns don't appear to be implemented at all.
Setup: a simple self-referencing property graph over an employee/manager table.
CREATE PROPERTY GRAPH city_org_graph
VERTEX TABLES ( city_org KEY (id) LABEL employee PROPERTIES ALL COLUMNS )
EDGE TABLES (
city_org AS reports_to
KEY (id)
SOURCE KEY (id) REFERENCES city_org (id)
DESTINATION KEY (manager_id) REFERENCES city_org (id)
LABEL reports_to
NO PROPERTIES
);
I tried both forms the standard defines for repeating a path: a quantifier directly on an edge, and a quantified nested group. I was trying to walk from an employee up to the root of the org chart at unknown depth:
MATCH (a IS employee WHERE a.name = 'Leo Park') -[IS reports_to]->{1,10} (root IS employee)
-- ERROR: element pattern quantifier is not supported
MATCH (a IS employee WHERE a.name = 'Leo Park') (-[IS reports_to]->(IS employee)){1,10} (root IS employee)
-- ERROR: unsupported element pattern kind: "nested path pattern"
Both are parsed far enough to be recognized and then explicitly rejected, rather than a plain syntax error, so this doesn't look like a mistake on my end — it reads like the feature genuinely isn't there yet. I retested identically on a fresh PostgreSQL 18.6-based rebuild just to rule out anything environment-specific, and separately re-ran the same two queries against PG19 beta3 after it was tagged; the errors are byte-for-byte identical to what PG19 beta2 produced.
A few questions, if anyone can point me in the right direction:
1. Is quantified path pattern support intentionally deferred past 19, or is there a patch/commitfest entry already in flight that I should be watching?
2. If it's deferred, is there a tracking thread or open item I could link to, so the book can point readers at the right place instead of just saying "not yet"?
3. Is there a recommended workaround inside SQL/PGQ itself for unbounded-depth traversal, or is a recursive CTE still the correct answer for that case in 19?
Happy to share the full reproduction (it's a self-contained example, no extensions, just core PG19) if that's useful. Thanks for all the work getting SQL/PGQ this far — the fixed-depth pattern matching and undirected edge support are genuinely nice additions.
Thanks,
Chris
[1] https://chrislee35.github.io/postgresql-beyond-relational-lab-book/
