Skip to content

P
Postgres FD Implementation
Commit 95af0cb9 authored by Thomas G. Lockhart's avatar Thomas G. Lockhart
Browse files
Options

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

parent 4dce924b
Hide whitespace changes
Inline Side-by-side
Showing with 269 additions and 284 deletions
doc/src/sgml/ref/declare.sgml
View file @ 95af0cb9
<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>
......@@ -29,56 +30,117 @@
</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>
......@@ -87,16 +149,11 @@
</TITLE>
<PARA>
</PARA>
<VARIABLELIST>
<VARLISTENTRY>
<TERM>
</TERM>
<LISTITEM>
<PARA>
<VARIABLELIST>
<VARLISTENTRY>
<TERM>
<ReturnValue>SELECT</ReturnValue>
SELECT
</TERM>
<LISTITEM>
<PARA>
......@@ -104,10 +161,11 @@
</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>
......@@ -115,16 +173,25 @@
</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
......@@ -132,39 +199,55 @@
<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
......@@ -173,8 +256,9 @@
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>
......@@ -207,49 +291,14 @@
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
......
doc/src/sgml/ref/fetch.sgml
View file @ 95af0cb9
......@@ -17,7 +17,9 @@ Gets rows using a cursor
<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">
......@@ -36,7 +38,8 @@ Inputs
</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>
......@@ -46,8 +49,8 @@ FORWARD
</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>
......@@ -57,15 +60,35 @@ BACKWARD
<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>
......@@ -75,6 +98,24 @@ ALL
<PARA>
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>
<TERM>
<REPLACEABLE CLASS="PARAMETER">cursor</REPLACEABLE>
......@@ -108,6 +149,34 @@ NOTICE: PerformPortalFetch: portal "<REPLACEABLE CLASS="PARAMETER">cursor</REPL
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>
......@@ -122,13 +191,30 @@ Description
</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
......@@ -138,8 +224,9 @@ Description
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
......@@ -216,87 +303,25 @@ Compatibility
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>
......
doc/src/sgml/ref/move.sgml
View file @ 95af0cb9
......@@ -18,105 +18,11 @@ Moves cursor position
<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>
......@@ -125,9 +31,13 @@ NOTICE: PerformPortalFetch: portal <REPLACEABLE CLASS="PARAMETER">cursor</REPLA
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>
......@@ -140,9 +50,9 @@ Notes
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.
......@@ -195,5 +105,6 @@ Compatibility
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>
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