Author: jstephens
Date: 2006-04-01 13:12:34 +0200 (Sat, 01 Apr 2006)
New Revision: 1716
Log:
Reformat.
Modified:
trunk/refman-5.1/events.xml
trunk/refman-5.1/information-schema.xml
trunk/refman-5.1/sql-syntax.xml
Modified: trunk/refman-5.1/events.xml
===================================================================
--- trunk/refman-5.1/events.xml 2006-04-01 11:08:53 UTC (rev 1715)
+++ trunk/refman-5.1/events.xml 2006-04-01 11:12:34 UTC (rev 1716)
@@ -318,8 +318,7 @@
<listitem>
<para>
New events are defined using the <literal>CREATE
- EVENT</literal> statement. See
- <xref linkend="create-event"/>.
+ EVENT</literal> statement. See <xref linkend="create-event"/>.
</para>
</listitem>
@@ -622,7 +621,7 @@
<literal>ENDS</literal>, both, or neither in an
<literal>EVERY</literal> clause.
</para>
-
+
<para>
<emphasis role="bold">Note</emphasis>: Where
<literal>STARTS</literal> or <literal>ENDS</literal> is
@@ -1339,12 +1338,12 @@
<para>
The resolution of event schedules is measured 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
+ 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.
@@ -1377,13 +1376,13 @@
<para>
Events cannot be created with a start time that is in the past.
</para>
-
+
<para>
Events do not support times later than the end of the Unix Epoch;
- this is approximately the end of the year 2037). 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)
+ this is approximately the end of the year 2037). 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>
@@ -1411,19 +1410,19 @@
DATABASE</literal>) statement. See
<xref linkend="rename-database"/>.
</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 with the same definer,
and having the names <literal>anEvent</literal> and
- <literal>AnEvent</literal>.
+ <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.
+ later.
</para>
</section>
Modified: trunk/refman-5.1/information-schema.xml
===================================================================
--- trunk/refman-5.1/information-schema.xml 2006-04-01 11:08:53 UTC (rev 1715)
+++ trunk/refman-5.1/information-schema.xml 2006-04-01 11:12:34 UTC (rev 1716)
@@ -3997,10 +3997,10 @@
clears the table once per day.
1 row in set (0.50 sec)
</programlisting>
-
+
<para>
- <emphasis role="bold">Important</emphasis>: The times displayed
- by the <literal>STARTS</literal>, <literal>ENDS</literal>, and
+ <emphasis role="bold">Important</emphasis>: The times displayed by
+ the <literal>STARTS</literal>, <literal>ENDS</literal>, and
<literal>LAST_EXECUTED</literal> columns are always given in terms
of Universal Time (GMT or UTC), regardless of the the server's
time zone setting. (The same is true for the
@@ -4014,7 +4014,7 @@
<literal>created</literal> and <literal>last_altered</literal>
columns of the <literal>mysql.event</literal> table).
</para>
-
+
<para>
For example, the <literal>e_daily</literal> event shown previously
was created on a computer in Brisbane, Australia, at 14:35:35 on
@@ -4395,12 +4395,12 @@
<literal>EXTENT_SIZE</literal> becomes, the less accurate the
approximations are.
</para>
-
+
<para>
- It is also important to remember that once an extent is used, it
- cannot be freed again without dropping the datafile of which it is a
- part. This means that deletes from a Disk Data table do
- <emphasis>not</emphasis> release disk space.
+ It is also important to remember that once an extent is used,
+ it cannot be freed again without dropping the datafile of
+ which it is a part. This means that deletes from a Disk Data
+ table do <emphasis>not</emphasis> release disk space.
</para>
<para>
@@ -4676,10 +4676,10 @@
</informaltable>
<para>
- For an extensive description of the table columns, see
+ For an extensive description of the table columns, see
<xref linkend="show-processlist"/>.
</para>
-
+
<para>
<emphasis role="bold">Notes</emphasis>:
</para>
@@ -4692,23 +4692,25 @@
table. It was added in MySQL 5.1.7.
</para>
</listitem>
-
+
<listitem>
<para>
- Like the output from the corresponding <literal>SHOW</literal> statement,
- the <literal>PROCESSLIST</literal> table will only show
- information about your own threads, unless you have the
- <literal>PROCESS</literal> privilege, in which case you will see information about other threads, too. As an anonymous user, you cannot see any rows at all.
+ Like the output from the corresponding <literal>SHOW</literal>
+ statement, the <literal>PROCESSLIST</literal> table will only
+ show information about your own threads, unless you have the
+ <literal>PROCESS</literal> privilege, in which case you will
+ see information about other threads, too. As an anonymous
+ user, you cannot see any rows at all.
</para>
</listitem>
-
+
<listitem>
<para>
- If an SQL statement refers to
- <literal>INFORMATION_SCHEMA.PROCESSLIST</literal>,
- then MySQL will populate the entire table once, when statement
- execution begins, so there is read consistency during the
- statement. There is no read consistency for a multi-statement
+ If an SQL statement refers to
+ <literal>INFORMATION_SCHEMA.PROCESSLIST</literal>, then MySQL
+ will populate the entire table once, when statement execution
+ begins, so there is read consistency during the statement.
+ There is no read consistency for a multi-statement
transaction, though.
</para>
</listitem>
@@ -4724,7 +4726,7 @@
SHOW PROCESSLIST
</programlisting>
-
+
</section>
<section id="other-information-schema-tables">
Modified: trunk/refman-5.1/sql-syntax.xml
===================================================================
--- trunk/refman-5.1/sql-syntax.xml 2006-04-01 11:08:53 UTC (rev 1715)
+++ trunk/refman-5.1/sql-syntax.xml 2006-04-01 11:12:34 UTC (rev 1716)
@@ -10518,12 +10518,11 @@
</listitem>
</itemizedlist>
-
+
<para>
Since truncation of a table does not make any use of
<literal>DELETE</literal>, the <literal>TRUNCATE</literal>
- statement does not invoke <literal>ON DELETE</literal>
- triggers.
+ statement does not invoke <literal>ON DELETE</literal> triggers.
</para>
<para>
@@ -16927,7 +16926,7 @@
Note that the action statement is not shown in the output of
<literal>SHOW EVENTS</literal>.
</para>
-
+
<para>
<emphasis role="bold">Note</emphasis>: The values displayed
for <literal>Starts</literal> and <literal>Ends</literal>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r1716 - trunk/refman-5.1 | jon | 1 Apr |
