Add note that LIMIT without ORDER BY can produce outright nondeterministic

results.  Necessary due to introduction of syncscan patch.

diff --git a/doc/src/sgml/ref/select.sgml b/doc/src/sgml/ref/select.sgml
index 0f1ada97cb60303fce5ec728bc5e86d026860c41..2165a63d4a142e759e5d9ecf262e9b809392eed6 100644 (file)
--- a/doc/src/sgml/ref/select.sgml
+++ b/doc/src/sgml/ref/select.sgml
@@ -1,5 +1,5 @@
 <!--
-$PostgreSQL: pgsql/doc/src/sgml/ref/select.sgml,v 1.100 2007/05/15 19:13:55 neilc Exp $
+$PostgreSQL: pgsql/doc/src/sgml/ref/select.sgml,v 1.101 2007/06/08 20:26:18 tgl Exp $
 PostgreSQL documentation
 -->
 
@@ -810,6 +810,14 @@ OFFSET <replaceable class="parameter">start</replaceable>
     to deliver the results of a query in any particular order unless
     <literal>ORDER BY</> is used to constrain the order.
    </para>
+
+   <para>
+    It is even possible for repeated executions of the same <literal>LIMIT</>
+    query to return different subsets of the rows of a table, if there
+    is not an <literal>ORDER BY</> to enforce selection of a deterministic
+    subset.  Again, this is not a bug; determinism of the results is
+    simply not guaranteed in such a case.
+   </para>
   </refsect2>
 
   <refsect2 id="SQL-FOR-UPDATE-SHARE">