> Actually, if you submit a patch that says either "SCROLL is the

default"
> or "NO SCROLL is the default", it will be rejected as incorrect.  The
> reason is that the default behavior is different from either of these,
> as is explained in the NOTES section.

Ok, so *that's* where the bit about the query plan being simple enough.
Based on that, ISTM that it should be premissable for us to decide that
a cursor requiring a sort isn't "simple enough" to support SCROLL.

In any case, here's a patch that makes the non-standard behavior easier
for people to find.

Jim C. Nasby

diff --git a/doc/src/sgml/ref/declare.sgml b/doc/src/sgml/ref/declare.sgml
index f43e08f970df4390e922137805de3dd39aad2ce1..40e25f99add07ff855ac45ef619c8010c1b9e045 100644 (file)
--- a/doc/src/sgml/ref/declare.sgml
+++ b/doc/src/sgml/ref/declare.sgml
@@ -1,5 +1,5 @@
 
 
@@ -129,7 +129,9 @@ DECLARE name [ BINARY ] [ INSENSITI
       execution plan, specifying SCROLL may impose
       a performance penalty on the query's execution time.
       NO SCROLL specifies that the cursor cannot be
-      used to retrieve rows in a nonsequential fashion.
+      used to retrieve rows in a nonsequential fashion.  The default is to
+      allow scrolling, but this is not the same as specifying
+      SCROLL. See  for more details.
      
     
    
@@ -198,7 +200,7 @@ DECLARE name [ BINARY ] [ INSENSITI
   
  
 
- 
+  id="notes">
   Notes