2 ms·
The graph database feature looks interesting, but I wonder... SELECT customer_name FROM GRAPH_TABLE (myshop MATCH (c IS customers)-[IS customer_orders]->(o IS
by mickeyp 3mo ago
The graph database feature looks interesting, but I wonder...
SELECT customer_name FROM GRAPH_TABLE (myshop MATCH (c IS customers)-[IS customer_orders]->(o IS orders WHERE o.ordered_when = current_date) COLUMNS (c.name AS customer_name));
That is _awful_ syntax; it is reminiscent of neo4j, which is surely not a tool anyone serious should copy from outright in 2026.
And of course the final thing I am left wondering is if it's fast. Row-level security is such a useful feature and yet only a fool would contemplate building anything serious with Postgres', as the planner goes haywire and does per-row-matching, nuking performance.
- hobofan 3mo agoThat is not a homebrew sytax that Postgres came up with themselves. It's SQL/PGQ, which was derived from the Cypher language for Neo4J and now is part of the SQL standard.
- mickeyp 3mo agoFair --- but I feel my criticism stands. It's awful. Don't get me started on 80% of all deployment uses of neo4j...
- sgarland 3mo ago> [RLS]… planner goes haywire and does per-row-matching Er… yes? It’s called Row-level security; how else are you going to validate that a row passes a policy?
- mickeyp 3mo agoThe same way other databases do it. With join mechanics and proper query planning. You're confusing functionality with implementation.