Author: jstephens
Date: 2007-08-15 10:37:50 +0200 (Wed, 15 Aug 2007)
New Revision: 7453
Log:
Event Limitations:
Fake headings -> formalparas
Harmonise 5.1->5.2 versions
Modified:
trunk/refman-5.1/events.xml
trunk/refman-5.2/events.xml
Modified: trunk/refman-5.1/events.xml
===================================================================
--- trunk/refman-5.1/events.xml 2007-08-15 07:49:10 UTC (rev 7452)
+++ trunk/refman-5.1/events.xml 2007-08-15 08:37:50 UTC (rev 7453)
Changed blocks: 1, Lines Added: 204, Lines Deleted: 112; 13281 bytes
@@ -1932,134 +1932,226 @@
<para>
This section lists restrictions and limitations applying to event
- scheduling in MySQL.
+ scheduling in MySQL ¤t-series;.
</para>
- <para>
- In MySQL 5.1.6, any table referenced in an event's action
- statement must be fully qualified with the name of the schema in
- which it occurs (that is, as
- <literal><replaceable>schema_name</replaceable>.<replaceable>table_name</replaceable></literal>).
- </para>
+ <formalpara>
- <para>
- An event may not be created, altered, or dropped by a trigger,
- stored routine, or another event. An event also may not create,
- alter, or drop triggers or stored routines. (Bug #16409, Bug
- #18896)
- </para>
+ <title>Qualification of identifiers</title>
- <para>
- Event timings using the intervals <literal>YEAR</literal>,
- <literal>QUARTER</literal>, <literal>MONTH</literal>, and
- <literal>YEAR_MONTH</literal> are resolved in months; those using
- any other interval are resolved in seconds. There is no way to
- cause events scheduled to occur at the same second to execute in a
- given order. In addition — due to rounding, the nature of
- threaded applications, and the fact that a non-zero length of time
- is required to create events and to signal their execution —
- events may be delayed by as much as 1 or 2 seconds. However, the
- time shown in the <literal>INFORMATION_SCHEMA.EVENTS</literal>
- table's <literal>LAST_EXECUTED</literal> column or the
- <literal>mysql.event</literal> table's
- <literal>last_executed</literal> column is always accurate to
- within one second of the time the event was actually executed.
- (See also Bug #16522.)
- </para>
+ <para>
+ In MySQL 5.1.6 only, any table referenced in an event's action
+ statement must be fully qualified with the name of the schema in
+ which it occurs (that is, as
+ <literal><replaceable>schema_name</replaceable>.<replaceable>table_name</replaceable></literal>).
+ </para>
- <para>
- Execution of event statements has no effect on the server's
- statement counts such as <literal>Com_select</literal> and
- <literal>Com_insert</literal> that are displayed by <literal>SHOW
- STATUS</literal>.
- </para>
+ </formalpara>
- <para>
- Prior to MySQL 5.1.12, you could not view another user's events in
- the <literal>INFORMATION_SCHEMA.EVENTS</literal> table. In other
- words, any query made against this table was treated as though it
- contained the condition <literal>DEFINER =
- CURRENT_USER()</literal> in the <literal>WHERE</literal> clause.
- </para>
+ <formalpara>
- <para>
- Events cannot be created with a start time that is in the past.
- </para>
+ <title>Case sensitivity of event identifiers</title>
- <para>
- Events do not support times later than the end of the Unix Epoch;
- this is approximately the end of the year 2038. Prior to MySQL
- 5.1.8, handling in scheduled events of dates later than this was
- buggy; starting with MySQL 5.1.8, such dates are specifically
- disallowed by the Event Scheduler. (Bug #16396)
- </para>
+ <para>
+ Beginning with MySQL 5.1.8, event names are handled in
+ case-insensitive fashion. For example, this means that you
+ cannot have two events in the same database (and — prior
+ to MySQL 5.1.12 — with the same definer) with the names
+ <literal>anEvent</literal> and <literal>AnEvent</literal>.
- <para>
- In MySQL 5.1.6, <literal>INFORMATION_SCHEMA.EVENTS</literal> shows
- <literal>NULL</literal> in the <literal>SQL_MODE</literal> column.
- Beginning with MySQL 5.1.7, the <literal>SQL_MODE</literal>
- displayed is that in effect when the event was created.
- </para>
+ <important>
+ <para>
+ If you have events created in MySQL 5.1.7 or earlier, which
+ are assigned to the same database and have the same definer,
+ and whose names differ only with respect to lettercase, then
+ you must rename these events to respect case-sensitive
+ handling before upgrading to MySQL 5.1.8 or later.
+ </para>
+ </important>
+ </para>
- <para>
- In MySQL 5.1.6, the only way to drop or alter an event created by
- a user who was not the definer of that event was by manipulation
- of the <literal>mysql.event</literal> system table by the MySQL
- <literal>root</literal> user or by another user with privileges on
- this table. Beginning with MySQL 5.1.7, <literal>DROP
- USER</literal> drops all events for which that user was the
- definer; also beginning with MySQL 5.1.7 <literal>DROP
- SCHEMA</literal> drops all events associated with the dropped
- schema.
- </para>
+ </formalpara>
- <para>
- As with stored routines, events are not migrated to the new schema
- by the <literal>RENAME SCHEMA</literal> (or <literal>RENAME
- DATABASE</literal>) statement. See
- <xref linkend="rename-database"/>.
- </para>
+ <formalpara>
- <para>
- Beginning with MySQL 5.1.8, event names are handled in
- case-insensitive fashion. For example, this means that you cannot
- have two events in the same database (and — prior to MySQL
- 5.1.12 — with the same definer) with the names
- <literal>anEvent</literal> and <literal>AnEvent</literal>.
- <emphasis role="bold">Important</emphasis>: If you have events
- created in MySQL 5.1.7 or earlier, which are assigned to the same
- database and have the same definer, and whose names differ only
- with respect to lettercase, then you must rename these events to
- respect case-sensitive handling before upgrading to MySQL 5.1.8 or
- later.
- </para>
+ <title>Modification of events by stored routines and triggers</title>
- <para>
- References to stored routines, user-defined functions, and tables
- in the <literal>ON SCHEDULE</literal> clauses of <literal>CREATE
- EVENT</literal> and <literal>ALTER EVENT</literal> statements are
- not supported. Beginning with MySQL 5.1.13, these sorts of
- references are disallowed. (See Bug #22830 for more information.)
- </para>
+ <para>
+ An event may not be created, altered, or dropped by a trigger,
+ stored routine, or another event. An event also may not create,
+ alter, or drop triggers or stored routines. (Bug #16409, Bug
+ #18896)
+ </para>
- <para>
- Generally speaking, statements which are not permitted in stored
- routines or in SQL prepared statements are also not allowed in the
- body of an event. See <xref linkend="routine-restrictions"/>, and
- <xref linkend="sqlps"/>, for more information.
- </para>
+ </formalpara>
- <para>
- When upgrading to MySQL 5.1.18 or later from a previous MySQL
- version where scheduled events were in use, the upgrade utilities
- <command>mysql_upgrade</command> and
- <command>mysql_fix_privilege_tables</command> do not accomodate
- changes in system tables relating to the Event Scheduler. As a
- workaround, you can dump events before the upgrade, then restore
- them from the dump afterwards. This issue was fixed in MySQL
- 5.1.20 (see Bug #28521).
- </para>
+ <formalpara>
+ <title>Resolution of event timings</title>
+
+ <para>
+ Event timings using the intervals <literal>YEAR</literal>,
+ <literal>QUARTER</literal>, <literal>MONTH</literal>, and
+ <literal>YEAR_MONTH</literal> are resolved in months; those
+ using any other interval are resolved in seconds. There is no
+ way to cause events scheduled to occur at the same second to
+ execute in a given order. In addition — due to rounding,
+ the nature of threaded applications, and the fact that a
+ non-zero length of time is required to create events and to
+ signal their execution — events may be delayed by as much
+ as 1 or 2 seconds. However, the time shown in the
+ <literal>INFORMATION_SCHEMA.EVENTS</literal> table's
+ <literal>LAST_EXECUTED</literal> column or the
+ <literal>mysql.event</literal> table's
+ <literal>last_executed</literal> column is always accurate to
+ within one second of the time the event was actually executed.
+ (See also Bug #16522.)
+ </para>
+
+ </formalpara>
+
+ <formalpara>
+
+ <title>Effects on statement counts</title>
+
+ <para>
+ Execution of event statements has no effect on the server's
+ statement counts such as <literal>Com_select</literal> and
+ <literal>Com_insert</literal> that are displayed by
+ <literal>SHOW STATUS</literal>.
+ </para>
+
+ </formalpara>
+
+ <formalpara>
+
+ <title>Visibility of events belonging to other users</title>
+
+ <para>
+ Prior to MySQL 5.1.12, you could not view another user's events
+ in the <literal>INFORMATION_SCHEMA.EVENTS</literal> table. In
+ other words, any query made against this table was treated as
+ though it contained the condition <literal>DEFINER =
+ CURRENT_USER()</literal> in the <literal>WHERE</literal> clause.
+ </para>
+
+ </formalpara>
+
+ <formalpara>
+
+ <title>Start times</title>
+
+ <para>
+ Events cannot be created with a start time that is in the past.
+ </para>
+
+ </formalpara>
+
+ <formalpara>
+
+ <title>Latest time supported</title>
+
+ <para>
+ Events do not support times later than the end of the Unix
+ Epoch; this is approximately the end of the year 2038. Prior to
+ MySQL 5.1.8, handling in scheduled events of dates later than
+ this was buggy; starting with MySQL 5.1.8, such dates are
+ specifically disallowed by the Event Scheduler. (Bug #16396)
+ </para>
+
+ </formalpara>
+
+ <formalpara>
+
+ <title>Server SQL mode</title>
+
+ <para>
+ In MySQL 5.1.6, <literal>INFORMATION_SCHEMA.EVENTS</literal>
+ shows <literal>NULL</literal> in the <literal>SQL_MODE</literal>
+ column. Beginning with MySQL 5.1.7, the
+ <literal>SQL_MODE</literal> displayed is that in effect when the
+ event was created.
+ </para>
+
+ </formalpara>
+
+ <formalpara>
+
+ <title>Dropping or altering events</title>
+
+ <para>
+ In MySQL 5.1.6, the only way to drop or alter an event created
+ by a user who was not the definer of that event was by
+ manipulation of the <literal>mysql.event</literal> system table
+ by the MySQL <literal>root</literal> user or by another user
+ with privileges on this table. Beginning with MySQL 5.1.7,
+ <literal>DROP USER</literal> drops all events for which that
+ user was the definer; also beginning with MySQL 5.1.7
+ <literal>DROP SCHEMA</literal> drops all events associated with
+ the dropped schema.
+ </para>
+
+ </formalpara>
+
+ <formalpara>
+
+ <title>Schema migration not supported</title>
+
+ <para>
+ As with stored routines, events are not migrated to the new
+ schema by the <literal>RENAME SCHEMA</literal> (or
+ <literal>RENAME DATABASE</literal>) statement. See
+ <xref linkend="rename-database"/>.
+ </para>
+
+ </formalpara>
+
+ <formalpara>
+
+ <title>Database object references in <literal>ON SCHEDULE</literal> clauses</title>
+
+ <para>
+ References to stored routines, user-defined functions, and
+ tables in the <literal>ON SCHEDULE</literal> clauses of
+ <literal>CREATE EVENT</literal> and <literal>ALTER
+ EVENT</literal> statements are not supported. Beginning with
+ MySQL 5.1.13, these sorts of references are disallowed. (See Bug
+ #22830 for more information.)
+ </para>
+
+ </formalpara>
+
+ <formalpara>
+
+ <title>Disallowed statements</title>
+
+ <para>
+ Generally speaking, statements which are not permitted in stored
+ routines or in SQL prepared statements are also not allowed in
+ the body of an event. See
+ <xref linkend="routine-restrictions"/>, and
+ <xref linkend="sqlps"/>, for more information.
+ </para>
+
+ </formalpara>
+
+ <formalpara>
+
+ <title>Upgrading to MySQL 5.1.18 or later</title>
+
+ <para>
+ When upgrading to MySQL 5.1.18 or later from a previous MySQL
+ version where scheduled events were in use, the upgrade
+ utilities <command>mysql_upgrade</command> and
+ <command>mysql_fix_privilege_tables</command> do not accomodate
+ changes in system tables relating to the Event Scheduler. As a
+ workaround, you can dump events before the upgrade, then restore
+ them from the dump afterwards. This issue was fixed in MySQL
+ 5.1.20 (see Bug #28521).
+ </para>
+
+ </formalpara>
+
</section>
</chapter>
Modified: trunk/refman-5.2/events.xml
===================================================================
--- trunk/refman-5.2/events.xml 2007-08-15 07:49:10 UTC (rev 7452)
+++ trunk/refman-5.2/events.xml 2007-08-15 08:37:50 UTC (rev 7453)
Changed blocks: 1, Lines Added: 141, Lines Deleted: 102; 10086 bytes
@@ -1932,123 +1932,162 @@
<para>
This section lists restrictions and limitations applying to event
- scheduling in MySQL.
+ scheduling in MySQL ¤t-series;.
</para>
- <para>
- In MySQL 5.1.6, any table referenced in an event's action
- statement must be fully qualified with the name of the schema in
- which it occurs (that is, as
- <literal><replaceable>schema_name</replaceable>.<replaceable>table_name</replaceable></literal>).
- </para>
+ <formalpara>
- <para>
- An event may not be created, altered, or dropped by a trigger,
- stored routine, or another event. An event also may not create,
- alter, or drop triggers or stored routines. (Bug #16409, Bug
- #18896)
- </para>
+ <title>Case sensitivity of event identifiers</title>
- <para>
- Event timings using the intervals <literal>YEAR</literal>,
- <literal>QUARTER</literal>, <literal>MONTH</literal>, and
- <literal>YEAR_MONTH</literal> are resolved in months; those using
- any other interval are resolved in seconds. There is no way to
- cause events scheduled to occur at the same second to execute in a
- given order. In addition — due to rounding, the nature of
- threaded applications, and the fact that a non-zero length of time
- is required to create events and to signal their execution —
- events may be delayed by as much as 1 or 2 seconds. However, the
- time shown in the <literal>INFORMATION_SCHEMA.EVENTS</literal>
- table's <literal>LAST_EXECUTED</literal> column or the
- <literal>mysql.event</literal> table's
- <literal>last_executed</literal> column is always accurate to
- within one second of the time the event was actually executed.
- (See also Bug #16522.)
- </para>
+ <para>
+ Event names are handled in case-insensitive fashion. For
+ example, this means that you cannot have two events in the same
+ database with the names <literal>anEvent</literal> and
+ <literal>AnEvent</literal>.
+ </para>
- <para>
- Execution of event statements has no effect on the server's
- statement counts such as <literal>Com_select</literal> and
- <literal>Com_insert</literal> that are displayed by <literal>SHOW
- STATUS</literal>.
- </para>
+ </formalpara>
- <para>
- Prior to MySQL 5.1.12, you could not view another user's events in
- the <literal>INFORMATION_SCHEMA.EVENTS</literal> table. In other
- words, any query made against this table was treated as though it
- contained the condition <literal>DEFINER =
- CURRENT_USER()</literal> in the <literal>WHERE</literal> clause.
- </para>
+ <formalpara>
- <para>
- Events cannot be created with a start time that is in the past.
- </para>
+ <title>Modification of events by stored routines and triggers</title>
- <para>
- Events do not support times later than the end of the Unix Epoch;
- this is approximately the end of the year 2038. Prior to MySQL
- 5.1.8, handling in scheduled events of dates later than this was
- buggy; starting with MySQL 5.1.8, such dates are specifically
- disallowed by the Event Scheduler. (Bug #16396)
- </para>
+ <para>
+ An event may not be created, altered, or dropped by a trigger,
+ stored routine, or another event. An event also may not create,
+ alter, or drop triggers or stored routines. (Bug #16409, Bug
+ #18896)
+ </para>
- <para>
- In MySQL 5.1.6, <literal>INFORMATION_SCHEMA.EVENTS</literal> shows
- <literal>NULL</literal> in the <literal>SQL_MODE</literal> column.
- Beginning with MySQL 5.1.7, the <literal>SQL_MODE</literal>
- displayed is that in effect when the event was created.
- </para>
+ </formalpara>
- <para>
- In MySQL 5.1.6, the only way to drop or alter an event created by
- a user who was not the definer of that event was by manipulation
- of the <literal>mysql.event</literal> system table by the MySQL
- <literal>root</literal> user or by another user with privileges on
- this table. Beginning with MySQL 5.1.7, <literal>DROP
- USER</literal> drops all events for which that user was the
- definer; also beginning with MySQL 5.1.7 <literal>DROP
- SCHEMA</literal> drops all events associated with the dropped
- schema.
- </para>
+ <formalpara>
- <para>
- As with stored routines, events are not migrated to the new schema
- by the <literal>RENAME SCHEMA</literal> (or <literal>RENAME
- DATABASE</literal>) statement. See
- <xref linkend="rename-database"/>.
- </para>
+ <title>Resolution of event timings</title>
- <para>
- Beginning with MySQL 5.1.8, event names are handled in
- case-insensitive fashion. For example, this means that you cannot
- have two events in the same database (and — prior to MySQL
- 5.1.12 — with the same definer) with the names
- <literal>anEvent</literal> and <literal>AnEvent</literal>.
- <emphasis role="bold">Important</emphasis>: If you have events
- created in MySQL 5.1.7 or earlier, which are assigned to the same
- database and have the same definer, and whose names differ only
- with respect to lettercase, then you must rename these events to
- respect case-sensitive handling before upgrading to MySQL 5.1.8 or
- later.
- </para>
+ <para>
+ Event timings using the intervals <literal>YEAR</literal>,
+ <literal>QUARTER</literal>, <literal>MONTH</literal>, and
+ <literal>YEAR_MONTH</literal> are resolved in months; those
+ using any other interval are resolved in seconds. There is no
+ way to cause events scheduled to occur at the same second to
+ execute in a given order. In addition — due to rounding,
+ the nature of threaded applications, and the fact that a
+ non-zero length of time is required to create events and to
+ signal their execution — events may be delayed by as much
+ as 1 or 2 seconds. However, the time shown in the
+ <literal>INFORMATION_SCHEMA.EVENTS</literal> table's
+ <literal>LAST_EXECUTED</literal> column or the
+ <literal>mysql.event</literal> table's
+ <literal>last_executed</literal> column is always accurate to
+ within one second of the time the event was actually executed.
+ (See also Bug #16522.)
+ </para>
- <para>
- References to stored routines, user-defined functions, and tables
- in the <literal>ON SCHEDULE</literal> clauses of <literal>CREATE
- EVENT</literal> and <literal>ALTER EVENT</literal> statements are
- not supported. Beginning with MySQL 5.1.13, these sorts of
- references are disallowed. (See Bug #22830 for more information.)
- </para>
+ </formalpara>
- <para>
- Generally speaking, statements which are not permitted in stored
- routines or in SQL prepared statements are also not allowed in the
- body of an event. See <xref linkend="routine-restrictions"/>, and
- <xref linkend="sqlps"/>, for more information.
- </para>
+ <formalpara>
+ <title>Effects on statement counts</title>
+
+ <para>
+ Execution of event statements has no effect on the server's
+ statement counts such as <literal>Com_select</literal> and
+ <literal>Com_insert</literal> that are displayed by
+ <literal>SHOW STATUS</literal>.
+ </para>
+
+ </formalpara>
+
+ <formalpara>
+
+ <title>Start times</title>
+
+ <para>
+ Events cannot be created with a start time that is in the past.
+ </para>
+
+ </formalpara>
+
+ <formalpara>
+
+ <title>Latest time supported</title>
+
+ <para>
+ Events do not support times later than the end of the Unix
+ Epoch; this is approximately the end of the year 2038. Such
+ dates are specifically disallowed by the Event Scheduler. (Bug
+ #16396)
+ </para>
+
+ </formalpara>
+
+ <formalpara>
+
+ <title>Server SQL mode</title>
+
+ <para>
+ The <literal>SQL_MODE</literal>
+ column<literal>INFORMATION_SCHEMA.EVENTS</literal> shows the
+ server SQL mode that was in effect when the event was created.
+ </para>
+
+ </formalpara>
+
+ <formalpara>
+
+ <title>Dropping or altering events</title>
+
+ <para>
+ <literal>DROP USER</literal> drops all events for which that
+ user was the definer; <literal>DROP SCHEMA</literal> drops all
+ events associated with the dropped schema.
+ </para>
+
+ </formalpara>
+
+ <formalpara>
+
+ <title>Schema migration not supported</title>
+
+ <para>
+ As with stored routines, events are not migrated to the new
+ schema by the <literal>RENAME SCHEMA</literal> (or
+ <literal>RENAME DATABASE</literal>) statement. See
+ <xref linkend="rename-database"/>.
+ </para>
+
+ </formalpara>
+
+ <formalpara>
+
+ <title>Database object references in <literal>ON SCHEDULE</literal> clauses</title>
+
+ <para>
+ References to stored routines, user-defined functions, and
+ tables in the <literal>ON SCHEDULE</literal> clauses of
+ <literal>CREATE EVENT</literal> and <literal>ALTER
+ EVENT</literal> statements are not supported. These sorts of
+ references are disallowed. (See Bug #22830 for more
+ information.)
+ </para>
+
+ </formalpara>
+
+ <formalpara>
+
+ <title>Disallowed statements</title>
+
+ <para>
+ Generally speaking, statements which are not permitted in stored
+ routines or in SQL prepared statements are also not allowed in
+ the body of an event. See
+ <xref linkend="routine-restrictions"/>, and
+ <xref linkend="sqlps"/>, for more information.
+ </para>
+
+ </formalpara>
+
</section>
</chapter>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r7453 - in trunk: refman-5.1 refman-5.2 | jon | 15 Aug |
