(mysql.info) cursor-restrictions
Info Catalog
(mysql.info) routine-restrictions
(mysql.info) restrictions
(mysql.info) subquery-restrictions
I.2 Restrictions on Server-Side Cursors
=======================================
Server-side cursors are implemented beginning with the C API in MySQL
5.0.2 via the `mysql_stmt_attr_set()' function. A server-side cursor
allows a result set to be generated on the server side, but not
transferred to the client except for those rows that the client
requests. For example, if a client executes a query but is only
interested in the first row, the remaining rows are not transferred.
In MySQL, a server-side cursor is materialized into a temporary table.
Initially, this is a `MEMORY' table, but is converted to a `MyISAM'
table if its size reaches the value of the `max_heap_table_size' system
variable. (Beginning with MySQL 5.0.14, the same temporary-table
implementation also is used for cursors in stored routines.) One
limitation of the implementation is that for a large result set,
retrieving its rows through a cursor might be slow.
Cursors are read-only; you cannot use a cursor to update rows.
`UPDATE WHERE CURRENT OF' and `DELETE WHERE CURRENT OF' are not
implemented, because updatable cursors are not supported.
Cursors are non-holdable (not held open after a commit).
Cursors are asensitive.
Cursors are non-scrollable.
Cursors are not named. The statement handler acts as the cursor ID.
You can have open only a single cursor per prepared statement. If you
need several cursors, you must prepare several statements.
You cannot use a cursor for a statement that generates a result set if
the statement is not supported in prepared mode. This includes
statements such as `CHECK TABLES', `HANDLER READ', and `SHOW BINLOG
EVENTS'.
Info Catalog
(mysql.info) routine-restrictions
(mysql.info) restrictions
(mysql.info) subquery-restrictions
automatically generated byinfo2html