From 06224652f23441588b9d50cab7311e2c6ec05414 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Tue, 14 Oct 2008 00:41:35 +0000 Subject: Add docs and regression test about sorting the output of a recursive query in depth-first search order. Upon close reading of SQL:2008, it seems that the spec's SEARCH DEPTH FIRST and SEARCH BREADTH FIRST options do not actually guarantee any particular result order: what they do is provide a constructed column that the user can then sort on in the outer query. So this is actually just as much functionality ... --- doc/src/sgml/queries.sgml | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) (limited to 'doc/src') diff --git a/doc/src/sgml/queries.sgml b/doc/src/sgml/queries.sgml index ef9383a2f71..283dd0a73dd 100644 --- a/doc/src/sgml/queries.sgml +++ b/doc/src/sgml/queries.sgml @@ -1,4 +1,4 @@ - + Queries @@ -1681,6 +1681,15 @@ SELECT * FROM search_graph; + + + The recursive query evaluation algorithm produces its output in + breadth-first search order. You can display the results in depth-first + search order by making the outer query ORDER BY a + path column constructed in this way. + + + A helpful trick for testing queries when you are not certain if they might loop is to place a LIMIT @@ -1699,7 +1708,9 @@ SELECT n FROM t LIMIT 100; This works because PostgreSQL's implementation evaluates only as many rows of a WITH query as are actually fetched by the parent query. Using this trick in production is not - recommended, because other systems might work differently. + recommended, because other systems might work differently. Also, it + usually won't work if you make the outer query sort the recursive query's + results or join them to some other table. -- cgit v1.2.3