diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml index 23299346e18..cb8bf7965cd 100644 --- a/doc/src/sgml/ddl.sgml +++ b/doc/src/sgml/ddl.sgml @@ -5808,7 +5808,9 @@ CREATE PROPERTY GRAPH myshop This graph could then be queried like this: -- get list of customers active today -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)); +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)); corresponding approximately to this relational query: @@ -5872,7 +5874,9 @@ CREATE PROPERTY GRAPH myshop With this definition, we can write a query like this: -SELECT customer_name FROM GRAPH_TABLE (myshop MATCH (c IS customer)-[IS has_placed]->(o IS "order" WHERE o.ordered_when = current_date) COLUMNS (c.name AS customer_name)); +SELECT customer_name FROM GRAPH_TABLE (myshop + MATCH (c IS customer)-[IS has_placed]->(o IS "order" WHERE o.ordered_when = current_date) + COLUMNS (c.name AS customer_name)); With the new labels the MATCH clause is now more intuitive. @@ -5911,7 +5915,9 @@ CREATE PROPERTY GRAPH myshop employees table to something, but it is allowed like this.) Then we can run a query like this (incomplete): -SELECT ... FROM GRAPH_TABLE (myshop MATCH (IS person WHERE name = '...')-[]->... COLUMNS (...)); +SELECT ... FROM GRAPH_TABLE (myshop + MATCH (IS person WHERE name = '...')-[]->... + COLUMNS (...)); This would automatically consider both the customers and the employees tables when looking for an edge with the diff --git a/doc/src/sgml/queries.sgml b/doc/src/sgml/queries.sgml index 3d729f983b5..bd1497ff80d 100644 --- a/doc/src/sgml/queries.sgml +++ b/doc/src/sgml/queries.sgml @@ -2768,7 +2768,9 @@ SELECT * FROM t; Consider this example from : -- get list of customers active today -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)); +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)); The graph query part happens inside the GRAPH_TABLE construct. As far as the rest of the query is concerned, this acts like a @@ -2777,7 +2779,9 @@ SELECT customer_name FROM GRAPH_TABLE (myshop MATCH (c IS customers)-[IS custome names can be assigned to the result, and the result can be joined with other tables, subsequently filtered, and so on, for example: -SELECT ... FROM GRAPH_TABLE (mygraph MATCH ... COLUMNS (...)) AS myresult (a, b, c) JOIN othertable USING (a) WHERE b > 0 ORDER BY c; +SELECT ... FROM GRAPH_TABLE (mygraph + MATCH ... + COLUMNS (...)) AS myresult (a, b, c) JOIN othertable USING (a) WHERE b > 0 ORDER BY c; @@ -2893,8 +2897,9 @@ SELECT ... FROM GRAPH_TABLE (mygraph MATCH ... COLUMNS (...)) AS myresult (a, b, For example (assuming appropriate definitions of the property graph as well as the underlying tables): -GRAPH_TABLE (mygraph MATCH (p IS person)-[h IS has]->(a IS account) - COLUMNS (p.name AS person_name, h.since AS has_account_since, a.num AS account_number) +GRAPH_TABLE (mygraph + MATCH (p IS person)-[h IS has]->(a IS account) + COLUMNS (p.name AS person_name, h.since AS has_account_since, a.num AS account_number)) WHERE clauses can be used inside element patterns to filter matches: