Commit 95af0cb9 authored by Thomas G. Lockhart's avatar Thomas G. Lockhart

Fix Postgres to support SQL92 syntax. Old syntax still works too.

parent 4dce924b
<REFENTRY ID="SQL-DECLARESTATEMENT-1"> <REFENTRY ID="SQL-DECLARE">
<REFMETA> <REFMETA>
<REFENTRYTITLE> <REFENTRYTITLE>
DECLARE STATEMENT DECLARE
</REFENTRYTITLE> </REFENTRYTITLE>
<REFMISCINFO>SQL - Language Statements</REFMISCINFO> <REFMISCINFO>SQL - Language Statements</REFMISCINFO>
</REFMETA> </REFMETA>
<REFNAMEDIV> <REFNAMEDIV>
<REFNAME> <REFNAME>
DECLARE STATEMENT DECLARE
</REFNAME> </REFNAME>
<REFPURPOSE> <REFPURPOSE>
Declares a cursor Defines a cursor for table access
</REFPURPOSE> </REFPURPOSE>
<REFSYNOPSISDIV> <REFSYNOPSISDIV>
<REFSYNOPSISDIVINFO> <REFSYNOPSISDIVINFO>
<DATE>1998-04-15</DATE> <DATE>1998-09-04</DATE>
</REFSYNOPSISDIVINFO> </REFSYNOPSISDIVINFO>
<SYNOPSIS> <SYNOPSIS>
DECLARE <replaceable class="parameter">cursor</replaceable> [ BINARY ] DECLARE <replaceable class="parameter">cursor</replaceable> [ BINARY ] [ INSENSITIVE ] [ SCROLL ]
FOR SELECT <replaceable class="parameter">query</replaceable> CURSOR FOR <replaceable class="parameter">query</replaceable>
[ FOR { READ ONLY | UPDATE [ OF <replaceable class="parameter">column</replaceable> [, ...] ] ]
</SYNOPSIS> </SYNOPSIS>
<REFSECT2 ID="R2-SQL-DECLARESTATEMENT-1"> <REFSECT2 ID="R2-SQL-DECLARE-1">
<REFSECT2INFO> <REFSECT2INFO>
<DATE>1998-04-15</DATE> <DATE>1998-04-15</DATE>
</REFSECT2INFO> </REFSECT2INFO>
...@@ -32,53 +33,114 @@ ...@@ -32,53 +33,114 @@
<VARIABLELIST> <VARIABLELIST>
<VARLISTENTRY> <VARLISTENTRY>
<TERM> <TERM>
<replaceable class="parameter">cursor</replaceable>
</TERM> </TERM>
<LISTITEM> <LISTITEM>
<PARA> <PARA>
<VARIABLELIST> The name of the cursor to be used in subsequent FETCH operations..
</PARA>
</LISTITEM>
</VARLISTENTRY>
<VARLISTENTRY> <VARLISTENTRY>
<TERM> <TERM>
<ReturnValue>BINARY</ReturnValue> BINARY
</TERM> </TERM>
<LISTITEM> <LISTITEM>
<PARA> <PARA>
The BINARY keyword causes the cursor to fetch data in binary Causes the cursor to fetch data in binary
rather than in ASCII format. rather than in text format.
</PARA> </PARA>
</LISTITEM> </LISTITEM>
</VARLISTENTRY> </VARLISTENTRY>
<VARLISTENTRY> <VARLISTENTRY>
<TERM> <TERM>
<ReturnValue><replaceable class="parameter">cursor</replaceable></ReturnValue> INSENSITIVE
</TERM> </TERM>
<LISTITEM> <LISTITEM>
<PARA> <PARA>
The cursor's name. <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> </PARA>
</LISTITEM> </LISTITEM>
</VARLISTENTRY> </VARLISTENTRY>
<VARLISTENTRY> <VARLISTENTRY>
<TERM> <TERM>
<ReturnValue><replaceable class="parameter">query</replaceable></ReturnValue> SCROLL
</TERM> </TERM>
<LISTITEM> <LISTITEM>
<PARA> <PARA>
An SQL query which will provide the rows to be governed by the <acronym>SQL92</acronym> keyword indicating that data may be retrieved
cursor. in multiple rows per FETCH operation. Since this is allowed at all times
by <productname>Postgres</productname> this keyword has no effect.
</PARA> </PARA>
</LISTITEM>
</VARLISTENTRY>
<VARLISTENTRY>
<TERM>
<replaceable class="parameter">query</replaceable>
</TERM>
<LISTITEM>
<PARA> <PARA>
An SQL query which will provide the rows to be governed by the
cursor.
Refer to the SELECT statement for further information about Refer to the SELECT statement for further information about
valid arguments. valid arguments.
</PARA> </PARA>
</LISTITEM> </LISTITEM>
</VARLISTENTRY> </VARLISTENTRY>
</variablelist>
<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> </LISTITEM>
</VARLISTENTRY> </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> </VARIABLELIST>
</REFSECT2> </REFSECT2>
<REFSECT2 ID="R2-SQL-DECLARESTATEMENT-2"> <REFSECT2 ID="R2-SQL-DECLARE-2">
<REFSECT2INFO> <REFSECT2INFO>
<DATE>1998-04-15</DATE> <DATE>1998-04-15</DATE>
</REFSECT2INFO> </REFSECT2INFO>
...@@ -87,44 +149,49 @@ ...@@ -87,44 +149,49 @@
</TITLE> </TITLE>
<PARA> <PARA>
</PARA> </PARA>
<VARIABLELIST> <VARIABLELIST>
<VARLISTENTRY> <VARLISTENTRY>
<TERM> <TERM>
SELECT
</TERM> </TERM>
<LISTITEM> <LISTITEM>
<PARA> <PARA>
<VARIABLELIST> The message returned if the SELECT is run successfully.
</PARA>
</LISTITEM>
</VARLISTENTRY>
<VARLISTENTRY> <VARLISTENTRY>
<TERM> <TERM>
<ReturnValue>SELECT</ReturnValue> NOTICE
BlankPortalAssignName: portal "<replaceable class="parameter">cursor</replaceable>" already exists
</TERM> </TERM>
<LISTITEM> <LISTITEM>
<PARA> <PARA>
The message returned if the SELECT is run successfully. This error occurs if cursor "<replaceable class="parameter">cursor</replaceable>" is already declared.
</PARA> </PARA>
</LISTITEM> </LISTITEM>
</VARLISTENTRY> </VARLISTENTRY>
<VARLISTENTRY> <VARLISTENTRY>
<TERM> <TERM>
<ReturnValue>NOTICE ERROR: Named portals may only be used in begin/end transaction blocks
BlankPortalAssignName: portal "<replaceable class="parameter">cursor</replaceable>" already exists</ReturnValue>
</TERM> </TERM>
<LISTITEM> <LISTITEM>
<PARA> <PARA>
This error occurs if cursor "<replaceable class="parameter">cursor</replaceable>" is already declared. This error occurs if the cursor is not declared within a transaction block.
</PARA> </PARA>
</LISTITEM> </LISTITEM>
</VARLISTENTRY> </VARLISTENTRY>
</variablelist>
</LISTITEM>
</VARLISTENTRY>
</VARIABLELIST> </VARIABLELIST>
</REFSECT2> </REFSECT2>
</REFSYNOPSISDIV> </REFSYNOPSISDIV>
<REFSECT1 ID="R1-SQL-DECLARESTATEMENT-1"> <REFSECT1 ID="R1-SQL-DECLARE-1">
<REFSECT1INFO> <REFSECT1INFO>
<DATE>1998-04-15</DATE> <DATE>1998-09-04</DATE>
</REFSECT1INFO> </REFSECT1INFO>
<TITLE> <TITLE>
Description Description
...@@ -132,39 +199,55 @@ ...@@ -132,39 +199,55 @@
<PARA> <PARA>
DECLARE allows a user to create cursors, which can be used to retrieve 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 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>
<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 data is stored natively in binary format, the system must
do a conversion to produce the ASCII format. In addition, do a conversion to produce the text format. In addition,
ASCII formats are often larger in size than binary format. text formats are often larger in size than the corresponding binary format.
Once the information comes back in ASCII, the client Once the information comes back in text form, the client
application often has to convert it to a binary format to application may have to convert it to a binary format to
manipulate it anyway. manipulate it anyway.
</PARA> </PARA>
<PARA> <PARA>
BINARY cursors give you back the data in the native binary BINARY cursors give you back the data in the native binary
representation. So binary cursors will tend to be a representation. So binary cursors will tend to be a
little faster since they suffer less conversion overhead. little faster since they suffer less conversion overhead.
For example, for an integer column, you get a C integer number like ^A <para>
using a binary cursor, while you get a string value like '1' As an example, if a query returns a value of one from an integer column,
using the non binary cursor. you would get a string of '1' with a default cursor
</PARA> 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> <PARA>
However, ASCII is architecture-neutral whereas binary However, string representation is architecture-neutral whereas binary
representation can differ between different machine architectures. representation can differ between different machine architectures.
Therefore, if your client machine and server machine use different 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. 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 ASCII, getting it back in ASCII will save you some
effort on the client side. effort on the client side.
</tip>
</PARA> </PARA>
<REFSECT2 ID="R2-SQL-DECLARESTATEMENT-3"> <REFSECT2 ID="R2-SQL-DECLARE-3">
<REFSECT2INFO> <REFSECT2INFO>
<DATE>1998-04-15</DATE> <DATE>1998-09-04</DATE>
</REFSECT2INFO> </REFSECT2INFO>
<TITLE> <TITLE>
Notes Notes
...@@ -173,8 +256,9 @@ ...@@ -173,8 +256,9 @@
Cursors are only available in transactions. Cursors are only available in transactions.
</PARA> </PARA>
<PARA> <PARA>
PostgreSQL does not have an explicit <command>OPEN cursor</command> <productname>Postgres</productname>
statement; a cursor is considered to be open when it is DECLAREd. does not have an explicit <command>OPEN cursor</command>
statement; a cursor is considered to be open when it is declared.
</PARA> </PARA>
</REFSECT2> </REFSECT2>
</refsect1> </refsect1>
...@@ -207,49 +291,14 @@ ...@@ -207,49 +291,14 @@
SQL92 SQL92
</TITLE> </TITLE>
<PARA> <PARA>
SQL92 specifies some additional capabilities for the DECLARE statement: <acronym>SQL92</acronym> allows cursors only in embedded <acronym>SQL</acronym>
</PARA> and in modules. <productname>Postgres</productname> permits cursors to be used
<synopsis> interactively.
DECLARE cursor [ INSENSITIVE ] [ SCROLL ] CURSOR <acronym>SQL92</acronym> allows embedded or modular cursors to
FOR SELECT expression update database information.
[ ORDER BY column [, ... ] [ ASC | DESC ] All <productname>Postgres</productname> cursors are readonly.
[ FOR { READ ONLY | UPDATE [ OF column [, ...] ] } ] The BINARY keyword is a <productname>Postgres</productname> extension.
</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>
</REFENTRY> </REFENTRY>
<!-- Keep this comment at the end of the file <!-- Keep this comment at the end of the file
......
...@@ -17,7 +17,9 @@ Gets rows using a cursor ...@@ -17,7 +17,9 @@ Gets rows using a cursor
<DATE>1998-09-01</DATE> <DATE>1998-09-01</DATE>
</REFSYNOPSISDIVINFO> </REFSYNOPSISDIVINFO>
<SYNOPSIS> <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> </SYNOPSIS>
<REFSECT2 ID="R2-SQL-FETCH-1"> <REFSECT2 ID="R2-SQL-FETCH-1">
...@@ -36,7 +38,8 @@ Inputs ...@@ -36,7 +38,8 @@ Inputs
</TERM> </TERM>
<LISTITEM> <LISTITEM>
<PARA> <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: the following:
<VARIABLELIST> <VARIABLELIST>
...@@ -46,8 +49,8 @@ FORWARD ...@@ -46,8 +49,8 @@ FORWARD
</TERM> </TERM>
<LISTITEM> <LISTITEM>
<PARA> <PARA>
fetch next row(s), it is assumed by default fetch next row(s). This is the default
if selector is omitted. if <REPLACEABLE CLASS="PARAMETER">selector</REPLACEABLE> is omitted.
<VARLISTENTRY> <VARLISTENTRY>
<TERM> <TERM>
...@@ -57,15 +60,35 @@ BACKWARD ...@@ -57,15 +60,35 @@ BACKWARD
<PARA> <PARA>
fetch previous row(s). fetch previous row(s).
<VARLISTENTRY>
<TERM>
RELATIVE
</TERM>
<LISTITEM>
<PARA>
Noise word for SQL92 compatibility.
</VARIABLELIST> </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> <VARLISTENTRY>
<TERM> <TERM>
<REPLACEABLE CLASS="PARAMETER">#</REPLACEABLE> <REPLACEABLE CLASS="PARAMETER">#</REPLACEABLE>
</TERM> </TERM>
<LISTITEM> <LISTITEM>
<PARA> <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> <VARLISTENTRY>
<TERM> <TERM>
...@@ -75,6 +98,24 @@ ALL ...@@ -75,6 +98,24 @@ ALL
<PARA> <PARA>
Retrieve all remaining rows. Retrieve all remaining rows.
<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> <VARLISTENTRY>
<TERM> <TERM>
<REPLACEABLE CLASS="PARAMETER">cursor</REPLACEABLE> <REPLACEABLE CLASS="PARAMETER">cursor</REPLACEABLE>
...@@ -108,6 +149,34 @@ NOTICE: PerformPortalFetch: portal "<REPLACEABLE CLASS="PARAMETER">cursor</REPL ...@@ -108,6 +149,34 @@ NOTICE: PerformPortalFetch: portal "<REPLACEABLE CLASS="PARAMETER">cursor</REPL
If <REPLACEABLE CLASS="PARAMETER">cursor</REPLACEABLE> is not previously declared. If <REPLACEABLE CLASS="PARAMETER">cursor</REPLACEABLE> is not previously declared.
The cursor must be declared within a transaction block. 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> </variablelist>
</REFSECT2> </REFSECT2>
...@@ -122,13 +191,30 @@ Description ...@@ -122,13 +191,30 @@ Description
</TITLE> </TITLE>
<PARA> <PARA>
FETCH allows a user to retrieve rows using a cursor. 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 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 Substituting the keyword ALL in place of a number will
cause all remaining rows in the cursor to be retrieved. cause all remaining rows in the cursor to be retrieved.
Instances may be fetched in both forward and backward Instances may be fetched in both FORWARD and BACKWARD
directions. The default direction is forward. 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> <para>
Once all rows are fetched, every other fetch access returns Once all rows are fetched, every other fetch access returns
...@@ -138,8 +224,9 @@ Description ...@@ -138,8 +224,9 @@ Description
Updating data in a cursor is not supported by Updating data in a cursor is not supported by
<productname>Postgres</productname>, <productname>Postgres</productname>,
because mapping cursor updates back to base tables is because mapping cursor updates back to base tables is
not generally possible, similarly to VIEW updates. Consequently, not generally possible, as is also the case with VIEW updates.
users must issue explicit replace commands to update data. Consequently,
users must issue explicit UPDATE commands to replace data.
<para> <para>
Cursors may only be used inside of transactions because Cursors may only be used inside of transactions because
...@@ -216,87 +303,25 @@ Compatibility ...@@ -216,87 +303,25 @@ Compatibility
SQL92 SQL92
</TITLE> </TITLE>
<PARA> <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> <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> [, ...] INTO :<REPLACEABLE CLASS="PARAMETER">variable</REPLACEABLE> [, ...]
</synopsis> </synopsis>
<VARIABLELIST> <VARIABLELIST>
<VARLISTENTRY> <VARLISTENTRY>
<TERM> <TERM>
<REPLACEABLE CLASS="PARAMETER">selector</REPLACEABLE> ABSOLUTE
</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>
</TERM> </TERM>
<LISTITEM> <LISTITEM>
<PARA> <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> <VARLISTENTRY>
<TERM> <TERM>
......
...@@ -18,105 +18,11 @@ Moves cursor position ...@@ -18,105 +18,11 @@ Moves cursor position
<DATE>1998-09-01</DATE> <DATE>1998-09-01</DATE>
</REFSYNOPSISDIVINFO> </REFSYNOPSISDIVINFO>
<SYNOPSIS> <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> </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"> <REFSECT1 ID="R1-SQL-MOVE-1">
<REFSECT1INFO> <REFSECT1INFO>
<DATE>1998-04-15</DATE> <DATE>1998-04-15</DATE>
...@@ -125,9 +31,13 @@ NOTICE: PerformPortalFetch: portal <REPLACEABLE CLASS="PARAMETER">cursor</REPLA ...@@ -125,9 +31,13 @@ NOTICE: PerformPortalFetch: portal <REPLACEABLE CLASS="PARAMETER">cursor</REPLA
Description Description
</TITLE> </TITLE>
<PARA> <PARA>
MOVE allows a user to move cursor position for specified MOVE allows a user to move cursor position a specified
number of rows. MOVE works like fetch command: it number of rows. MOVE works like the FETCH command, but only
fetches rows, but put them nowhere. 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"> <REFSECT2 ID="R2-SQL-MOVE-3">
<REFSECT2INFO> <REFSECT2INFO>
...@@ -140,9 +50,9 @@ Notes ...@@ -140,9 +50,9 @@ Notes
MOVE is a <productname>Postgres</productname> language extension. MOVE is a <productname>Postgres</productname> language extension.
<para> <para>
Refer to FETCH statements for further description Refer to FETCH for a description
of valid arguments. 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 Refer to BEGIN WORK, COMMIT WORK, ROLLBACK WORK statements
for further information about transactions. for further information about transactions.
...@@ -195,5 +105,6 @@ Compatibility ...@@ -195,5 +105,6 @@ Compatibility
SQL92 SQL92
</TITLE> </TITLE>
<PARA> <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> </REFENTRY>
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment