However, only variables declared before the bound cursor was
          declared will be substituted into it.  In either case the value to
          be passed is determined at the time of the <command>OPEN</command>.
          For example, another way to get the same effect as the
          <literal>curs3</literal> example above is
<programlisting>
DECLARE
    key integer;
    curs4 CURSOR FOR SELECT * FROM tenk1 WHERE unique1 = key;
BEGIN
    key := 42;
    OPEN curs4;
</programlisting>
         </para>
     </sect3>
   </sect2>

   <sect2 id="plpgsql-cursor-using">
    <title>Using Cursors</title>

    <para>
     Once a cursor has been opened, it can be manipulated with the
     statements described here.
    </para>

    <para>
     These manipulations need not occur in the same function that
     opened the cursor to begin with.  You can return a <type>refcursor</type>
     value out of a function and let the caller operate on the cursor.
     (Internally, a <type>refcursor</type> value is simply the string name
     of the portal containing the active query for the cursor.  This name
     can be passed around, assigned to other <type>refcursor</type> variables,
     and so on, without disturbing the portal.)
    </para>

    <para>
     All portals are implicitly closed at transaction end.  Therefore
     a <type>refcursor</type> value is usable to reference an open cursor
     only until the end of the transaction.
    </para>

    <sect3 id="plpgsql-cursor-using-fetch">
     <title><literal>FETCH</literal></title>

<synopsis>
FETCH <optional> <replaceable>direction</replaceable> { FROM | IN } </optional> <replaceable>cursor</replaceable> INTO <replaceable>target</replaceable>;
</synopsis>

    <para>
     <command>FETCH</command> retrieves the next row (in the indicated
     direction) from the
     cursor into a target, which might be a row variable, a record
     variable, or a comma-separated list of simple variables, just like
     <command>SELECT INTO</command>.  If there is no suitable row, the
     target is set to NULL(s).  As with <command>SELECT
     INTO</command>, the special variable <literal>FOUND</literal> can
     be checked to see whether a row was obtained or not.  If no row is
     obtained, the cursor is positioned after the last row or before the
     first row, depending on the movement direction.
    </para>

    <para>
     The <replaceable>direction</replaceable> clause can be any of the
     variants allowed in the SQL <xref linkend="sql-fetch"/>
     command except the ones that can fetch
     more than one row; namely, it can be
     <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>FORWARD</literal>, or
     <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.
    </para>

    <para>
     <replaceable>cursor</replaceable> must be the name of a <type>refcursor</type>
     variable that references an open cursor portal.
    </para>

    <para>
     Examples:
<programlisting>
FETCH curs1 INTO rowvar;
FETCH curs2 INTO foo, bar, baz;
FETCH LAST FROM curs3 INTO x, y;
FETCH RELATIVE -2 FROM curs4 INTO x;
</programlisting>
       </para>
     </sect3>

    <sect3 id="plpgsql-cursor-using-move">
     <title><literal>MOVE</literal></title>

<synopsis>
MOVE <optional> <replaceable>direction</replaceable>