The "variable length relationship" is specifying an exact length of '5'.

You could:

- Specify an exact length of 5:
`MATCH p=(start)-[*5]-(end) RETURN p`

- Specify an upper bounds of 5:
`MATCH p=(start)-[*..5]-(end) RETURN p`

- Specify a lower bound of 5:
`MATCH p=(start)-[*5..]-(end) RETURN p`

- Specify a range of 3 to 5:
`MATCH p=(start)-[*3..5]-(end) RETURN p`

- Specify all path lengths:
`MATCH p=(start)-[*]-(end) RETURN p`

About (1): Exact lengths are the most efficient if you *know* exactly how long the paths should be.

About (2): Upper bounds are great for getting the entire neighborhood within that length or shorter, though may contain more paths than you need as sub-paths will be matched for each longer path. Meaning that if `(a)--(b)--(c)`

matches, then so will `(a)--(b)`

and you'll get both paths in the result set.

About (3): Lower bounds with no upper bounds is probably never a great idea when `end`

is not known. More at (5)

About (4): A lower bound plus upper bound range around a known node is interesting, like a donut of the outer neighborhood.

About (5): Remember the redundancy of (2)? Multiply that by finding all reachable nodes in the graph from the starting node. Phew, wow. Best to avoid unless `end`

is known and you limit the results to `1`

path, effectively asking "is there a path from start to end".

Through all this keep in mind the not-so-obvious fact that `MATCH`

is finding paths, not graphs. On the receiving side, you need to stitch a graph back together from those paths. Neo4j Browser's graph visualization does that post-processing whenever a result set contains any graph elements (node, relationships or paths).

Best,

ABK