diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index 291545ee008..b70924f6e16 100644
--- a/doc/src/sgml/ddl.sgml
+++ b/doc/src/sgml/ddl.sgml
@@ -5788,7 +5788,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:
@@ -5852,7 +5854,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.
@@ -5891,7 +5895,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: