evokoa-admin
## Summary PostgreSQL SQL/PGQ introduces standard graph query syntax such as property graphs and graph table queries. pgGraph currently exposes graph functionality through SQL functions in the `graph` schema. This issue tracks research and design for whether a future SQL/PGQ-facing adapter could map PostgreSQL graph syntax onto pgGraph's existing runtime engine. ## Why this matters pgGraph is optimized as a graph execution layer over ordinary PostgreSQL tables. SQL/PGQ could provide a more familiar standards-based query surface while still using pgGraph's CSR-backed traversal engine underneath. We've had a lot of inbound community requests for this feature. So we want to ship it sometime next week. ## Scope This is a design/research issue, not an implementation issue yet. Investigate: - What SQL/PGQ concepts map cleanly to pgGraph's current table and edge registration model - Whether `CREATE PROPERTY GRAPH` metadata can map to existing `graph.add_table`, `graph.add_edge`, or discovery APIs - Which query shapes could map to existing pgGraph APIs: - bounded traversal - shortest path - weighted shortest path - path reconstruction - source search - Which SQL/PGQ features do not currently fit pgGraph's model - Whether an adapter should be implemented inside pgGraph or kept as documentation/examples first ## Non-goals - Do not implement a separate graph database - Do not replace PostgreSQL as the source of truth - Do not add a second storage model - Do not degrade existing SQL function APIs