> 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 ce3a32b680161afb5b0501e8fe7355911b2b90a6..2229fa73f9749f7293192cf2b154563bd8954523 100644 (file)
--- a/doc/src/sgml/ref/declare.sgml
+++ b/doc/src/sgml/ref/declare.sgml
@@ -129,7 +129,9 @@ DECLARE <replaceable class="parameter">name</replaceable> [ BINARY ] [ INSENSITI
       execution plan, specifying <literal>SCROLL</literal> may impose
       a performance penalty on the query's execution time.
       <literal>NO SCROLL</literal> 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
+      <literal>SCROLL</literal>. See <xref linkend="notes"> for more details.
      </para>
     </listitem>
    </varlistentry>
@@ -198,7 +200,7 @@ DECLARE <replaceable class="parameter">name</replaceable> [ BINARY ] [ INSENSITI
   </para>
  </refsect1>
 
- <refsect1>
+ <refsect1 id="notes">
   <title>Notes</title>
 
    <para>