-<REFENTRY ID="SQL-DECLARESTATEMENT-1">
+<REFENTRY ID="SQL-DECLARE">
<REFMETA>
<REFENTRYTITLE>
- DECLARE STATEMENT
+ DECLARE
</REFENTRYTITLE>
<REFMISCINFO>SQL - Language Statements</REFMISCINFO>
</REFMETA>
<REFNAMEDIV>
<REFNAME>
- DECLARE STATEMENT
+ DECLARE
</REFNAME>
<REFPURPOSE>
- Declares a cursor
+ Defines a cursor for table access
</REFPURPOSE>
<REFSYNOPSISDIV>
<REFSYNOPSISDIVINFO>
- <DATE>1998-04-15</DATE>
+ <DATE>1998-09-04</DATE>
</REFSYNOPSISDIVINFO>
<SYNOPSIS>
- DECLARE <replaceable class="parameter">cursor</replaceable> [ BINARY ]
- FOR SELECT <replaceable class="parameter">query</replaceable>
+DECLARE <replaceable class="parameter">cursor</replaceable> [ BINARY ] [ INSENSITIVE ] [ SCROLL ]
+ CURSOR FOR <replaceable class="parameter">query</replaceable>
+ [ FOR { READ ONLY | UPDATE [ OF <replaceable class="parameter">column</replaceable> [, ...] ] ]
</SYNOPSIS>
- <REFSECT2 ID="R2-SQL-DECLARESTATEMENT-1">
+ <REFSECT2 ID="R2-SQL-DECLARE-1">
<REFSECT2INFO>
<DATE>1998-04-15</DATE>
</REFSECT2INFO>
</TITLE>
<PARA>
</PARA>
- <VARIABLELIST>
- <VARLISTENTRY>
- <TERM>
- </TERM>
- <LISTITEM>
- <PARA>
<VARIABLELIST>
<VARLISTENTRY>
<TERM>
- <ReturnValue>BINARY</ReturnValue>
+ <replaceable class="parameter">cursor</replaceable>
</TERM>
<LISTITEM>
<PARA>
- The BINARY keyword causes the cursor to fetch data in binary
- rather than in ASCII format.
+ The name of the cursor to be used in subsequent FETCH operations..
</PARA>
</LISTITEM>
</VARLISTENTRY>
+
<VARLISTENTRY>
<TERM>
- <ReturnValue><replaceable class="parameter">cursor</replaceable></ReturnValue>
+ BINARY
</TERM>
<LISTITEM>
<PARA>
- The cursor's name.
+ Causes the cursor to fetch data in binary
+ rather than in text format.
</PARA>
</LISTITEM>
</VARLISTENTRY>
+
<VARLISTENTRY>
<TERM>
- <ReturnValue><replaceable class="parameter">query</replaceable></ReturnValue>
+ INSENSITIVE
</TERM>
<LISTITEM>
<PARA>
- An SQL query which will provide the rows to be governed by the
- cursor.
+ <acronym>SQL92</acronym> keyword indicating that data retrieved
+from the cursor should be unaffected by updates from other processes or cursors.
+Since cursor operations occur within transactions
+ in <productname>Postgres</productname> this is always the case.
+This keyword has no effect.
+ </PARA>
+ </LISTITEM>
+ </VARLISTENTRY>
+
+ <VARLISTENTRY>
+ <TERM>
+ SCROLL
+ </TERM>
+ <LISTITEM>
+ <PARA>
+<acronym>SQL92</acronym> keyword indicating that data may be retrieved
+in multiple rows per FETCH operation. Since this is allowed at all times
+by <productname>Postgres</productname> this keyword has no effect.
</PARA>
+ </LISTITEM>
+ </VARLISTENTRY>
+
+ <VARLISTENTRY>
+ <TERM>
+ <replaceable class="parameter">query</replaceable>
+ </TERM>
+ <LISTITEM>
<PARA>
+ An SQL query which will provide the rows to be governed by the
+ cursor.
Refer to the SELECT statement for further information about
valid arguments.
</PARA>
</LISTITEM>
</VARLISTENTRY>
- </variablelist>
- </LISTITEM>
- </VARLISTENTRY>
+
+ <VARLISTENTRY>
+ <TERM>
+ READ ONLY
+ </TERM>
+ <LISTITEM>
+ <PARA>
+<acronym>SQL92</acronym> keyword indicating that the cursor will be used
+in a readonly mode. Since this is the only cursor access mode
+available in <productname>Postgres</productname> this keyword has no effect.
+ </PARA>
+ </LISTITEM>
+ </VARLISTENTRY>
+
+ <VARLISTENTRY>
+ <TERM>
+ UPDATE
+ </TERM>
+ <LISTITEM>
+ <PARA>
+<acronym>SQL92</acronym> keyword indicating that the cursor will be used
+to update tables. Since cursor updates are not currently
+supported in <productname>Postgres</productname> this keyword
+provokes an informational error message.
+ </PARA>
+ </LISTITEM>
+ </VARLISTENTRY>
+
+ <VARLISTENTRY>
+ <TERM>
+ <replaceable class="parameter">column</replaceable>
+ </TERM>
+ <LISTITEM>
+ <PARA>
+Column(s) to be updated.
+Since cursor updates are not currently
+supported in <productname>Postgres</productname> the UPDATE clause
+provokes an informational error message.
+ </PARA>
+ </LISTITEM>
+ </VARLISTENTRY>
+
</VARIABLELIST>
</REFSECT2>
- <REFSECT2 ID="R2-SQL-DECLARESTATEMENT-2">
+ <REFSECT2 ID="R2-SQL-DECLARE-2">
<REFSECT2INFO>
<DATE>1998-04-15</DATE>
</REFSECT2INFO>
</TITLE>
<PARA>
</PARA>
+
<VARIABLELIST>
- <VARLISTENTRY>
- <TERM>
- </TERM>
- <LISTITEM>
- <PARA>
- <VARIABLELIST>
<VARLISTENTRY>
<TERM>
- <ReturnValue>SELECT</ReturnValue>
+ SELECT
</TERM>
<LISTITEM>
<PARA>
</PARA>
</LISTITEM>
</VARLISTENTRY>
+
<VARLISTENTRY>
<TERM>
- <ReturnValue>NOTICE
- BlankPortalAssignName: portal "<replaceable class="parameter">cursor</replaceable>" already exists</ReturnValue>
+ NOTICE
+ BlankPortalAssignName: portal "<replaceable class="parameter">cursor</replaceable>" already exists
</TERM>
<LISTITEM>
<PARA>
</PARA>
</LISTITEM>
</VARLISTENTRY>
- </variablelist>
- </LISTITEM>
- </VARLISTENTRY>
+
+ <VARLISTENTRY>
+ <TERM>
+ERROR: Named portals may only be used in begin/end transaction blocks
+ </TERM>
+ <LISTITEM>
+ <PARA>
+This error occurs if the cursor is not declared within a transaction block.
+ </PARA>
+ </LISTITEM>
+ </VARLISTENTRY>
+
</VARIABLELIST>
</REFSECT2>
</REFSYNOPSISDIV>
- <REFSECT1 ID="R1-SQL-DECLARESTATEMENT-1">
+ <REFSECT1 ID="R1-SQL-DECLARE-1">
<REFSECT1INFO>
- <DATE>1998-04-15</DATE>
+ <DATE>1998-09-04</DATE>
</REFSECT1INFO>
<TITLE>
Description
<PARA>
DECLARE allows a user to create cursors, which can be used to retrieve
a small number of rows at a time out of a larger query. Cursors can return
- data either in ASCII or in binary foramt.
+ data either in text or in binary foramt.
</PARA>
<PARA>
- Normal cursors return data in ASCII format. Since
+ Normal cursors return data in text format, either ASCII or another
+encoding scheme depending on how the <productname>Postgres</productname>
+backend was built. Since
data is stored natively in binary format, the system must
- do a conversion to produce the ASCII format. In addition,
- ASCII formats are often larger in size than binary format.
- Once the information comes back in ASCII, the client
- application often has to convert it to a binary format to
+ do a conversion to produce the text format. In addition,
+ text formats are often larger in size than the corresponding binary format.
+ Once the information comes back in text form, the client
+ application may have to convert it to a binary format to
manipulate it anyway.
</PARA>
<PARA>
BINARY cursors give you back the data in the native binary
representation. So binary cursors will tend to be a
little faster since they suffer less conversion overhead.
- For example, for an integer column, you get a C integer number like ^A
- using a binary cursor, while you get a string value like '1'
- using the non binary cursor.
- </PARA>
+<para>
+ As an example, if a query returns a value of one from an integer column,
+you would get a string of '1' with a default cursor
+whereas with a binary cursor you would get
+ a 4-byte value equal to control-A ('^A').
+
+<caution>
+<para>
+BINARY cursors should be used carefully. User applications such
+as <application>psql</application> are not aware of binary cursors
+and expect data to come back in a text format.
+</caution>
+
<PARA>
- However, ASCII is architecture-neutral whereas binary
+ However, string representation is architecture-neutral whereas binary
representation can differ between different machine architectures.
Therefore, if your client machine and server machine use different
- representations, you will probably not want your data returned in
+ representations (e.g. "big-endian" versus "little-endian"),
+ you will probably not want your data returned in
binary format.
- Again, if you intend to display the data in
+
+<tip>
+<para>
+ If you intend to display the data in
ASCII, getting it back in ASCII will save you some
effort on the client side.
+</tip>
</PARA>
- <REFSECT2 ID="R2-SQL-DECLARESTATEMENT-3">
+ <REFSECT2 ID="R2-SQL-DECLARE-3">
<REFSECT2INFO>
- <DATE>1998-04-15</DATE>
+ <DATE>1998-09-04</DATE>
</REFSECT2INFO>
<TITLE>
Notes
Cursors are only available in transactions.
</PARA>
<PARA>
- PostgreSQL does not have an explicit <command>OPEN cursor</command>
- statement; a cursor is considered to be open when it is DECLAREd.
+ <productname>Postgres</productname>
+ does not have an explicit <command>OPEN cursor</command>
+ statement; a cursor is considered to be open when it is declared.
</PARA>
</REFSECT2>
</refsect1>
SQL92
</TITLE>
<PARA>
- SQL92 specifies some additional capabilities for the DECLARE statement:
- </PARA>
- <synopsis>
- DECLARE cursor [ INSENSITIVE ] [ SCROLL ] CURSOR
- FOR SELECT expression
- [ ORDER BY column [, ... ] [ ASC | DESC ]
- [ FOR { READ ONLY | UPDATE [ OF column [, ...] ] } ]
- </synopsis>
- <variablelist>
- <varlistentry>
- <term></term>
- <listitem>
- <variablelist>
- <varlistentry>
- <term>INSENSITIVE</term>
- <listitem>
- <para>
- UPDATE and DELETE CURRENT operations are not allowed
- if the cursor is declared to be INSENSITIVE.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>SCROLL</term>
- <listitem>
- <para>
- If SCROLL is not specified, only FETCH NEXT will be allowed.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>FOR READ ONLY/UPDATE</term>
- <listitem>
- <para>
- If READ ONLY is specified, UPDATE/DELETE CURRENT operations
- will not be allowed.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
- </listitem>
- </varlistentry>
- </variablelist>
+<acronym>SQL92</acronym> allows cursors only in embedded <acronym>SQL</acronym>
+and in modules. <productname>Postgres</productname> permits cursors to be used
+interactively.
+<acronym>SQL92</acronym> allows embedded or modular cursors to
+update database information.
+All <productname>Postgres</productname> cursors are readonly.
+The BINARY keyword is a <productname>Postgres</productname> extension.
+
</REFENTRY>
<!-- Keep this comment at the end of the file
<DATE>1998-09-01</DATE>
</REFSYNOPSISDIVINFO>
<SYNOPSIS>
-FETCH [ <REPLACEABLE CLASS="PARAMETER">selector</REPLACEABLE> ] { [ <REPLACEABLE CLASS="PARAMETER">#</REPLACEABLE> | ALL ] } { IN | FROM } <REPLACEABLE CLASS="PARAMETER">cursor</REPLACEABLE>
+FETCH [ <REPLACEABLE CLASS="PARAMETER">selector</REPLACEABLE> ] [ <REPLACEABLE CLASS="PARAMETER">count</REPLACEABLE> ]
+ { IN | FROM } <REPLACEABLE CLASS="PARAMETER">cursor</REPLACEABLE>
+FETCH [ RELATIVE ] [ { [ <REPLACEABLE CLASS="PARAMETER">#</REPLACEABLE> | ALL | NEXT | PRIOR ] } ] FROM ] <REPLACEABLE CLASS="PARAMETER">cursor</REPLACEABLE>
</SYNOPSIS>
<REFSECT2 ID="R2-SQL-FETCH-1">
</TERM>
<LISTITEM>
<PARA>
-Selector define fetch direction and it can be one
+<REPLACEABLE CLASS="PARAMETER">selector</REPLACEABLE>
+defines the fetch direction. It can be one
the following:
<VARIABLELIST>
</TERM>
<LISTITEM>
<PARA>
-fetch next row(s), it is assumed by default
- if selector is omitted.
+fetch next row(s). This is the default
+ if <REPLACEABLE CLASS="PARAMETER">selector</REPLACEABLE> is omitted.
<VARLISTENTRY>
<TERM>
<PARA>
fetch previous row(s).
+<VARLISTENTRY>
+<TERM>
+RELATIVE
+</TERM>
+<LISTITEM>
+<PARA>
+Noise word for SQL92 compatibility.
+
</VARIABLELIST>
<VARLISTENTRY>
<TERM>
+<REPLACEABLE CLASS="PARAMETER">count</REPLACEABLE>
+</TERM>
+<LISTITEM>
+<PARA>
+<REPLACEABLE CLASS="PARAMETER">count</REPLACEABLE>
+determines how many rows to fetch. It can be one of the following:
+
+<VARIABLELIST>
+<VARLISTENTRY>
+<TERM>
<REPLACEABLE CLASS="PARAMETER">#</REPLACEABLE>
</TERM>
<LISTITEM>
<PARA>
-An unsigned integer that specify how many rows to fetch.
+A signed integer that specify how many rows to fetch.
+Note that a negative integer is equivalent to changing the sense of
+FORWARD and BACKWARD.
<VARLISTENTRY>
<TERM>
<VARLISTENTRY>
<TERM>
+NEXT
+</TERM>
+<LISTITEM>
+<PARA>
+Equivalent to specifying a count of <command>1</command>.
+
+<VARLISTENTRY>
+<TERM>
+PRIOR
+</TERM>
+<LISTITEM>
+<PARA>
+Equivalent to specifying a count of <command>-1</command>.
+
+</VARIABLELIST>
+
+<VARLISTENTRY>
+<TERM>
<REPLACEABLE CLASS="PARAMETER">cursor</REPLACEABLE>
</TERM>
<LISTITEM>
If <REPLACEABLE CLASS="PARAMETER">cursor</REPLACEABLE> is not previously declared.
The cursor must be declared within a transaction block.
+<VARLISTENTRY>
+<TERM>
+NOTICE: FETCH/ABSOLUTE not supported, using RELATIVE
+</TERM>
+<LISTITEM>
+<PARA>
+<productname>Postgres</productname> does not support absolute
+positioning of cursors.
+
+<VARLISTENTRY>
+<TERM>
+ERROR: FETCH/RELATIVE at current position is not supported
+</TERM>
+<LISTITEM>
+<PARA>
+<acronym>SQL92</acronym> allows one to repetatively retrieve the cursor
+at its "current position" using the syntax
+<programlisting>
+FETCH RELATIVE 0 FROM <REPLACEABLE CLASS="PARAMETER">cursor</REPLACEABLE>
+</programlisting>
+
+<productname>Postgres</productname> does not currently support
+this notion; in fact the value zero is reserved to indicate that
+all rows should be retrieved and is equivalent to specifying the ALL keyword.
+If the RELATIVE keyword has been used, the <productname>Postgres</productname>
+assumes that the user intended <acronym>SQL92</acronym> behavior
+and returns this error message.
+
</variablelist>
</REFSECT2>
</TITLE>
<PARA>
FETCH allows a user to retrieve rows using a cursor.
- The number of rows retrieved is specified by #.
+ The number of rows retrieved is specified by
+ <REPLACEABLE CLASS="PARAMETER">#</REPLACEABLE>.
If the number of rows remaining in the cursor is less
- than #, then only those available are fetched.
+ than <REPLACEABLE CLASS="PARAMETER">#</REPLACEABLE>,
+ then only those available are fetched.
Substituting the keyword ALL in place of a number will
cause all remaining rows in the cursor to be retrieved.
- Instances may be fetched in both forward and backward
- directions. The default direction is forward.
+ Instances may be fetched in both FORWARD and BACKWARD
+ directions. The default direction is FORWARD.
+
+<tip>
+<para>
+Negative numbers are now allowed to be specified for the
+row count. A negative number is equivalent to reversing
+the sense of the FORWARD and BACKWARD keywords. For example,
+<command>FORWARD -1</command> is the same as <command>BACKWARD 1</command>.
+</tip>
+
+<para>
+Note that the FORWARD and BACKWARD keywords are
+ <productname>Postgres</productname> extensions.
+The <acronym>SQL92</acronym> syntax is also supported, specified
+in the second form of the command. See below for details
+on compatibility issues.
<para>
Once all rows are fetched, every other fetch access returns
Updating data in a cursor is not supported by
<productname>Postgres</productname>,
because mapping cursor updates back to base tables is
-not generally possible, similarly to VIEW updates. Consequently,
- users must issue explicit replace commands to update data.
+not generally possible, as is also the case with VIEW updates.
+ Consequently,
+ users must issue explicit UPDATE commands to replace data.
<para>
Cursors may only be used inside of transactions because
SQL92
</TITLE>
<PARA>
- SQL92 specifies some additional capabilities for FETCH statement.
+SQL92 allows absolute positioning of the cursor for
+FETCH, and allows placing the results into explicit variables.
<synopsis>
-FETCH [ [ <REPLACEABLE CLASS="PARAMETER">selector</REPLACEABLE> ] FROM ] <REPLACEABLE CLASS="PARAMETER">cursor</REPLACEABLE>
+FETCH ABSOLUTE <REPLACEABLE CLASS="PARAMETER">#</REPLACEABLE>
+ FROM <REPLACEABLE CLASS="PARAMETER">cursor</REPLACEABLE>
INTO :<REPLACEABLE CLASS="PARAMETER">variable</REPLACEABLE> [, ...]
</synopsis>
<VARIABLELIST>
<VARLISTENTRY>
<TERM>
-<REPLACEABLE CLASS="PARAMETER">selector</REPLACEABLE>
-</TERM>
-<LISTITEM>
-<PARA>
-Defines the fetch direction with one of the following values:
-
-<VARIABLELIST>
-<VARLISTENTRY>
-<TERM>
-NEXT
-</TERM>
-<LISTITEM>
-<PARA>
-Fetch next row, it is assumed by default
- if selector is omitted.
- This is the only legal selector unless cursor is
- declared with the SCROLL option.
-
-<VARLISTENTRY>
-<TERM>
-PRIOR
-</TERM>
-<LISTITEM>
-<PARA>
-Fetch previous row.
-
-<VARLISTENTRY>
-<TERM>
-FIRST
-</TERM>
-<LISTITEM>
-<PARA>
-Fetch first row.
-
-<VARLISTENTRY>
-<TERM>
-LAST
-</TERM>
-<LISTITEM>
-<PARA>
-Fetch last row.
-
-<VARLISTENTRY>
-<TERM>
-ABSOLUTE <REPLACEABLE CLASS="PARAMETER">#</REPLACEABLE>
-</TERM>
-<LISTITEM>
-<PARA>
-Refers to the <REPLACEABLE CLASS="PARAMETER">#</REPLACEABLE>th row
- in the table associated with the cursor.
-
-<VARLISTENTRY>
-<TERM>
-RELATIVE <REPLACEABLE CLASS="PARAMETER">#</REPLACEABLE>
-</TERM>
-<LISTITEM>
-<PARA>
-Refers to the <REPLACEABLE CLASS="PARAMETER">#</REPLACEABLE>th row
- relative to the cursor position.
-A negative number is equivalent to reversing the sense of the FORWARD and
- BACKWARD keywords.
-
-</variablelist>
-
-<VARLISTENTRY>
-<TERM>
-<REPLACEABLE CLASS="PARAMETER">cursor</REPLACEABLE>
+ABSOLUTE
</TERM>
<LISTITEM>
<PARA>
-A cursor previously defined in the same transaction block using BEGIN and DECLARE.
+The cursor should be positioned to the specified absolute
+row number. All row numbers in <productname>Postgres</productname>
+are relative numbers so this capability is not supported.
<VARLISTENTRY>
<TERM>
<DATE>1998-09-01</DATE>
</REFSYNOPSISDIVINFO>
<SYNOPSIS>
-MOVE [ <REPLACEABLE CLASS="PARAMETER">selector</REPLACEABLE> ] { [ <REPLACEABLE CLASS="PARAMETER">#</REPLACEABLE> | ALL ] } IN <REPLACEABLE CLASS="PARAMETER">cursor</REPLACEABLE>
+MOVE [ <REPLACEABLE CLASS="PARAMETER">selector</REPLACEABLE> ] [ <REPLACEABLE CLASS="PARAMETER">count</REPLACEABLE> ]
+ { IN | FROM } <REPLACEABLE CLASS="PARAMETER">cursor</REPLACEABLE>
+FETCH [ RELATIVE ] [ { [ <REPLACEABLE CLASS="PARAMETER">#</REPLACEABLE> | ALL | NEXT | PRIOR ] } ] FROM ] <REPLACEABLE CLASS="PARAMETER">cursor</REPLACEABLE>
</SYNOPSIS>
-<REFSECT2 ID="R2-SQL-MOVE-1">
-<REFSECT2INFO>
-<DATE>1998-09-01</DATE>
-</REFSECT2INFO>
-<TITLE>
-Inputs
-</TITLE>
-<PARA>
-</PARA>
-<VARIABLELIST>
-<VARLISTENTRY>
-<TERM>
-<REPLACEABLE CLASS="PARAMETER">selector</REPLACEABLE>
-</TERM>
-<LISTITEM>
-<PARA>
-
-<variablelist>
-<varlistentry>
-<term>
-FORWARD
-</term>
-<listitem>
-<para>
-Skip next row(s), it is assumed by default
- if selector is omitted.
-
-<varlistentry>
-<term>
-BACKWARD
-</term>
-<listitem>
-<para>
-Skip previous row(s).
-
-</variablelist>
-
-<VARLISTENTRY>
-<TERM>
-<REPLACEABLE CLASS="PARAMETER">#</REPLACEABLE>
-</TERM>
-<LISTITEM>
-<PARA>
- An unsigned integer that specify how many rows to skip.
-
-<VARLISTENTRY>
-<TERM>
-ALL
-</TERM>
-<LISTITEM>
-<PARA>
-Skip all remaining rows.
-
-<VARLISTENTRY>
-<TERM>
-<REPLACEABLE CLASS="PARAMETER">cursor</REPLACEABLE>
-</TERM>
-<LISTITEM>
-<PARA>
- An open cursor's name.
-
-</VARIABLELIST>
-
-</REFSECT2>
-
-<REFSECT2 ID="R2-SQL-MOVE-2">
-<REFSECT2INFO>
-<DATE>1998-09-01</DATE>
-</REFSECT2INFO>
-<TITLE>
-Outputs
-</TITLE>
-<PARA>
-</PARA>
-<VARIABLELIST>
-<VARLISTENTRY>
-<TERM>
-MOVE
-</TERM>
-<LISTITEM>
-<PARA>
- Message returned if successfully.
-
-<VARLISTENTRY>
-<TERM>
-NOTICE: PerformPortalFetch: portal <REPLACEABLE CLASS="PARAMETER">cursor</REPLACEABLE> not found.
-</TERM>
-<LISTITEM>
-<PARA>
- If cursor is not declared.
-
-</VARIABLELIST>
-
-</REFSECT2>
-</REFSYNOPSISDIV>
-
<REFSECT1 ID="R1-SQL-MOVE-1">
<REFSECT1INFO>
<DATE>1998-04-15</DATE>
Description
</TITLE>
<PARA>
- MOVE allows a user to move cursor position for specified
- number of rows. MOVE works like fetch command: it
- fetches rows, but put them nowhere.
+ MOVE allows a user to move cursor position a specified
+ number of rows. MOVE works like the FETCH command, but only
+positions the cursor and does
+not return rows.
+
+<para>
+Refer to the FETCH command for details on syntax and usage.
<REFSECT2 ID="R2-SQL-MOVE-3">
<REFSECT2INFO>
MOVE is a <productname>Postgres</productname> language extension.
<para>
- Refer to FETCH statements for further description
+ Refer to FETCH for a description
of valid arguments.
- Refer to DECLARE statements to declare a cursor.
+ Refer to DECLARE to declare a cursor.
Refer to BEGIN WORK, COMMIT WORK, ROLLBACK WORK statements
for further information about transactions.
SQL92
</TITLE>
<PARA>
- There is no SQL92 MOVE statement.
+ There is no SQL92 MOVE statement. Instead, <acronym>SQL92</acronym> allows
+one to FETCH rows from an absolute cursor position.
</REFENTRY>
OSDN Git Service
