Below is the list of changes that have just been committed into a local
mysqldoc repository of paul. When paul does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://www.mysql.com/doc/I/n/Installing_source_tree.html
ChangeSet
1.2519 04/12/21 11:00:47 paul@stripped +1 -0
Merge paul@stripped:/home/bk/mysqldoc
into frost.snake.net:/Volumes/frost2/MySQL/bk/mysqldoc
Docs/manual.texi
1.2282 04/12/21 11:00:44 paul@stripped +0 -0
Auto merged
# This is a BitKeeper patch. What follows are the unified diffs for the
# set of deltas contained in the patch. The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User: paul
# Host: frost.snake.net
# Root: /Volumes/frost2/MySQL/bk/mysqldoc/RESYNC
--- 1.2281/Docs/manual.texi 2004-12-21 07:58:58 -06:00
+++ 1.2282/Docs/manual.texi 2004-12-21 11:00:44 -06:00
@@ -21378,6 +21378,10 @@
@item @code{ft_boolean_syntax} @tab numeric @tab @code{GLOBAL}
@item @code{group_concat_max_len} @tab numeric @tab @code{GLOBAL} | @code{SESSION}
@item @code{identity} @tab numeric @tab @code{SESSION}
+@c innodb_autoextend_increment: introduced in 4.1.5, made settable in 4.1.6
+@item @code{innodb_autoextend_increment} @tab numeric @tab @code{GLOBAL}
+@item @code{innodb_max_purge_lag} @tab numeric @tab @code{GLOBAL}
+@item @code{innodb_table_locks} @tab boolean @tab @code{GLOBAL} | @code{SESSION}
@item @code{insert_id} @tab boolean @tab @code{SESSION}
@item @code{interactive_timeout} @tab numeric @tab @code{GLOBAL} | @code{SESSION}
@item @code{join_buffer_size} @tab numeric @tab @code{GLOBAL} | @code{SESSION}
@@ -57377,8 +57381,67 @@
This statement creates a new view, or replaces an existing one if the
@code{OR REPLACE} clause is given. The @var{select_statement} is a
@code{SELECT} statement that provides the definition of the view.
-The optional column list can be given to define explicit names for the
-view columns.
+The statement can select from base tables or other views.
+
+A view belongs to a database. By default, a new view is created in the
+current database. To create the view explicitly in a given database,
+specify the name as @var{db_name.view_name} when you create it.
+
+@example
+mysql> CREATE VIEW test.v AS SELECT * FROM t;
+@end example
+
+Tables and views share the same namespace within a database, so a database
+cannot contain a table and a view that have the same name.
+
+Views must have unique column names with no duplicates, just like base
+tables. By default, the names of the columns retrieved by the @code{SELECT}
+statement are used for the view column names. To define explicit names for
+the view columns, the optional column list can be given. In this case, the
+number of names in @var{column_list} must be the same as the number of
+columns retrieved by the @code{SELECT} statement.
+
+Columns retrieved by the @code{SELECT} statement can be simple references to
+table columns. They can also be expressions that use operators, functions,
+constant values, and so forth.
+
+@c TODO: however, use of anything othe than simple column references
+@c makes view not updatable. Updatable views must select only table columns.
+
+A view can refer to columns of tables or views in other databases by
+qualifying the table or view name with the proper database name.
+
+A view definition is subject to the following constraints:
+
+@itemize @bullet
+
+@item
+The @code{SELECT} statement cannot contain a subquery in the @code{FROM}
+clause.
+
+@item
+The @code{SELECT} statement cannot refer to user variables.
+
+@item
+Within a stored procedure, the definition cannot refer to procedure
+parameters.
+
+@item
+Any table or view referred to in the definition must exist. However, after
+a view has been created, it is possible to drop a table or view that the
+definition refers to.
+@c TODO: add the following when CHECK VIEW gets pushed
+@c To check a view definition for problems of this kind, use the
+@c @code{CHECK VIEW} statement.
+
+@item
+The definition cannot refer to a @code{TEMPORARY} table, and you cannot
+create a @code{TEMPORARY} view.
+
+@item
+You cannot associate a trigger with a view.
+
+@end itemize
@c TODO: need to describe ALGORITHM clause
@@ -57406,14 +57469,6 @@
+------+-------+-------+
@end example
-By default, the view is in the current database. To create
-the view explicitly in a given database, specify the name as
-@var{db_name.view_name} when you create it.
-
-@example
-mysql> CREATE VIEW test.v AS SELECT * FROM t;
-@end example
-
In a @code{WITH CHECK OPTION} clause for an updatable view, the @code{LOCAL}
and @code{CASCADED} keywords determine the scope of check testing when the
view is defined in terms of another view. @code{LOCAL} keyword restricts
@@ -60640,9 +60695,11 @@
SHOW TABLE STATUS [FROM @var{db_name}] [LIKE '@var{pattern}']
@end example
-@code{SHOW TABLE STATUS} (new in MySQL 3.23) works likes @code{SHOW
-TABLE}, but provides a lot of information about each table. You can
-also get this list using the @command{mysqlshow --status @var{db_name}} command.
+@code{SHOW TABLE STATUS} works likes @code{SHOW TABLE}, but provides a lot
+of information about each table. You can also get this list using the
+@command{mysqlshow --status @var{db_name}} command. This statement was
+added in MySQL 3.23. As of MySQL 5.0.1, it also displays information about
+views.
@code{SHOW TABLE STATUS} returns the following fields:
@@ -60731,6 +60788,10 @@
actual amount of allocated memory. The allocation algorithm reserves memory
in large amounts to reduce the number of allocation operations.
+For views, all the fields displayed by @code{SHOW TABLE STATUS} are
+@code{NULL} except that @code{Name} indicates the view name and @code{Comment}
+says @code{view}.
+
@node SHOW TABLES, SHOW VARIABLES, SHOW TABLE STATUS, SHOW
@subsubsection @code{SHOW TABLES} Syntax
@@ -64496,7 +64557,7 @@
* Moving:: Moving an @code{InnoDB} Database to Another Machine
* InnoDB transaction model:: @code{InnoDB} Transaction Model and Locking
* InnoDB tuning:: @code{InnoDB} Performance Tuning Tips
-* Implementation:: Implementation of Multi-Versioning
+* InnoDB Multi-Versioning:: Implementation of Multi-Versioning
* Table and index:: Table and Index Structures
* File space management:: File Space Management and Disk I/O
* InnoDB Error handling:: Error Handling
@@ -64994,7 +65055,8 @@
@item innodb_autoextend_increment
The increment size (in megabytes) for extending the size of an autoextending
tablespace when it becomes full. The default value is 8.
-This option is available starting from MySQL 4.1.5.
+This option is available starting from MySQL 4.1.5. As of MySQL 4.1.6, it
+can be changed at runtime as a global system variable.
@item innodb_buffer_pool_awe_mem_mb
The size of the buffer pool (in MB), if it is placed in the AWE memory of
@@ -65246,6 +65308,15 @@
SET GLOBAL innodb_max_dirty_pages_pct = @var{value};
@end example
+@item innodb_max_purge_lag
+This option controls how to delay @code{INSERT}, @code{UPDATE}
+and @code{DELETE} operations when the purge operations are lagging.
+The default value of this parameter is zero, meaning that there will
+not be any delays. When the value is greater than zero, @code{InnoDB}
+may delay new row operations, as described in @ref{InnoDB Multi-Versioning}.
+This option can be changed at runtime as a global system variable.
+@code{innodb_max_purge_lag} is available as of MySQL 4.0.22 and 4.1.6.
+
@item innodb_mirrored_log_groups
The number of identical copies of log groups we keep for the
database. Currently this should be set to 1.
@@ -67075,7 +67146,7 @@
@end itemize
-@node InnoDB tuning, Implementation, InnoDB transaction model, InnoDB
+@node InnoDB tuning, InnoDB Multi-Versioning, InnoDB transaction model, InnoDB
@section @code{InnoDB} Performance Tuning Tips
@itemize @bullet
@@ -67506,7 +67577,7 @@
if the configuration option @code{innodb_status_file=1} is set.
-@node Implementation, Table and index, InnoDB tuning, InnoDB
+@node InnoDB Multi-Versioning, Table and index, InnoDB tuning, InnoDB
@section Implementation of Multi-Versioning
Because @code{InnoDB} is a multi-versioned database, it must keep information
@@ -67571,7 +67642,7 @@
Starting with MySQL/InnoDB-4.1.6 and 4.0.22, there is a startup option
and settable global variable @code{innodb_max_purge_lag}, which is
-zero by default. When this parameter is nonzero, InnoDB may delay new
+zero by default. When this parameter is non-zero, InnoDB may delay new
row operations. When the @var{purge_lag} exceeds
@code{innodb_max_purge_lag}, each @code{INSERT}, @code{UPDATE} and
@code{DELETE} operation will be delayed by
@@ -67583,7 +67654,7 @@
million, assuming that our transactions are small, only 100 bytes in
size, and we can allow @w{100 MB} of unpurged rows in our tables.
-@node Table and index, File space management, Implementation, InnoDB
+@node Table and index, File space management, InnoDB Multi-Versioning, InnoDB
@section Table and Index Structures
MySQL stores its data dictionary information for tables in @file{.frm}
@@ -94691,7 +94762,7 @@
@code{innodb_max_purge_lag} for delaying @code{INSERT}, @code{UPDATE}
and @code{DELETE} operations when the purge operations are lagging.
The default value of this parameter is zero, meaning that there will
-not be any delays. @xref{Implementation}.
+not be any delays. @xref{InnoDB Multi-Versioning}.
@item
InnoDB: The @code{innodb_autoextend_increment} startup option that was
introduced in release 4.1.5 was made a settable global variable. (Bug #5736)
@@ -96640,7 +96711,7 @@
@code{innodb_max_purge_lag} for delaying @code{INSERT}, @code{UPDATE}
and @code{DELETE} operations when the purge operations are lagging.
The default value of this parameter is zero, meaning that there will
-not be any delays. @xref{Implementation}.
+not be any delays. @xref{InnoDB Multi-Versioning}.
@item
InnoDB: Change error code to @code{HA_ERR_ROW_IS_REFERENCED} if we cannot
@code{DROP} a parent table because it is referenced by a
| Thread |
|---|
| • bk commit - mysqldoc tree (paul:1.2519) | paul | 21 Dec |