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/
