]> granicus.if.org Git - postgresql/commitdiff
Doc: minor improvement in pl/pgsql FETCH/MOVE documentation.
authorTom Lane <tgl@sss.pgh.pa.us>
Thu, 12 Jul 2018 16:28:43 +0000 (12:28 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Thu, 12 Jul 2018 16:29:03 +0000 (12:29 -0400)
Explain that you can use any integer expression for the "count" in
pl/pgsql's versions of FETCH/MOVE, unlike the SQL versions which only
allow a constant.

Remove the duplicate version of this para under MOVE.  I don't see
a good reason to maintain two identical paras when we just said that
MOVE works exactly like FETCH.

Per Pavel Stehule, though I didn't use his text.

Discussion: https://postgr.es/m/CAFj8pRAcvSXcNdUGx43bOK1e3NNPbQny7neoTLN42af+8MYWEA@mail.gmail.com

doc/src/sgml/plpgsql.sgml
doc/src/sgml/ref/fetch.sgml

index 5b2aac618e3c7392fd2eaa35d812fecf6623d36e..d6688e13f480d16c546334508a434f2a7622d312 100644 (file)
@@ -3196,6 +3196,10 @@ FETCH <optional> <replaceable>direction</replaceable> { FROM | IN } </optional>
      <literal>BACKWARD</literal>.
      Omitting <replaceable>direction</replaceable> is the same
      as specifying <literal>NEXT</literal>.
+     In the forms using a <replaceable>count</replaceable>,
+     the <replaceable>count</replaceable> can be any integer-valued
+     expression (unlike the SQL <command>FETCH</command> command,
+     which only allows an integer constant).
      <replaceable>direction</replaceable> values that require moving
      backward are likely to fail unless the cursor was declared or opened
      with the <literal>SCROLL</literal> option.
@@ -3233,26 +3237,6 @@ MOVE <optional> <replaceable>direction</replaceable> { FROM | IN } </optional> <
      be checked to see whether there was a next row to move to.
     </para>
 
-    <para>
-     The <replaceable>direction</replaceable> clause can be any of the
-     variants allowed in the SQL <xref linkend="sql-fetch"/>
-     command, namely
-     <literal>NEXT</literal>,
-     <literal>PRIOR</literal>,
-     <literal>FIRST</literal>,
-     <literal>LAST</literal>,
-     <literal>ABSOLUTE</literal> <replaceable>count</replaceable>,
-     <literal>RELATIVE</literal> <replaceable>count</replaceable>,
-     <literal>ALL</literal>,
-     <literal>FORWARD</literal> <optional> <replaceable>count</replaceable> | <literal>ALL</literal> </optional>, or
-     <literal>BACKWARD</literal> <optional> <replaceable>count</replaceable> | <literal>ALL</literal> </optional>.
-     Omitting <replaceable>direction</replaceable> is the same
-     as specifying <literal>NEXT</literal>.
-     <replaceable>direction</replaceable> values that require moving
-     backward are likely to fail unless the cursor was declared or opened
-     with the <literal>SCROLL</literal> option.
-    </para>
-
     <para>
      Examples:
 <programlisting>
index 5ef63f0058369b383e2b8a288e3aace05483cf67..e802be61c8c6dd81d550f636edf42edecced072e 100644 (file)
@@ -99,7 +99,7 @@ FETCH [ <replaceable class="parameter">direction</replaceable> [ FROM | IN ] ] <
     This page describes usage of cursors at the SQL command level.
     If you are trying to use cursors inside a <application>PL/pgSQL</application>
     function, the rules are different &mdash;
-    see <xref linkend="plpgsql-cursors"/>.
+    see <xref linkend="plpgsql-cursor-using"/>.
    </para>
   </note>
  </refsect1>