From: paul Date: January 21 2006 3:45am Subject: svn commit - mysqldoc@docsrva: r963 - in trunk: . refman-4.1 refman-5.0 refman-5.1 List-Archive: http://lists.mysql.com/commits/1432 Message-Id: <200601210345.k0L3jF2o004504@docsrva.mysql.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Author: paul Date: 2006-01-21 04:45:12 +0100 (Sat, 21 Jan 2006) New Revision: 963 Log: r6511@frost: paul | 2006-01-20 21:44:57 -0600 General revisions. Modified: trunk/ trunk/refman-4.1/connector-odbc.xml trunk/refman-4.1/database-administration.xml trunk/refman-4.1/functions.xml trunk/refman-4.1/innodb.xml trunk/refman-5.0/connector-odbc.xml trunk/refman-5.0/database-administration.xml trunk/refman-5.0/functions.xml trunk/refman-5.0/information-schema.xml trunk/refman-5.0/innodb.xml trunk/refman-5.0/storage-engines.xml trunk/refman-5.1/connector-odbc.xml trunk/refman-5.1/database-administration.xml trunk/refman-5.1/functions.xml trunk/refman-5.1/information-schema.xml trunk/refman-5.1/innodb.xml trunk/refman-5.1/storage-engines.xml Property changes on: trunk ___________________________________________________________________ Name: svk:merge - b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6506 bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2396 + b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6511 bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2396 Modified: trunk/refman-4.1/connector-odbc.xml =================================================================== --- trunk/refman-4.1/connector-odbc.xml 2006-01-21 03:10:02 UTC (rev 962) +++ trunk/refman-4.1/connector-odbc.xml 2006-01-21 03:45:12 UTC (rev 963) @@ -4141,8 +4141,8 @@ Tested with BDE 3.0. The only known problem is that when the table schema changes, query fields are not updated. BDE, however, does not seem to recognize primary keys, only the - index named PRIMARY, though this has not - been a problem. + index named PRIMARY, although this has + not been a problem. @@ -4218,7 +4218,7 @@ Enterprise 2000 to MySQL via MyODBC (2.50.37 or greater) and using Visio's reverse engineer function to retrieve information about the DB (Visio shows all the column - definitions, primary keys, Indexes and so on). Also we + definitions, primary keys, indexes and so on). Also, we tested by designing new tables in Visio and exported them to MySQL via MyODBC. Modified: trunk/refman-4.1/database-administration.xml =================================================================== --- trunk/refman-4.1/database-administration.xml 2006-01-21 03:10:02 UTC (rev 962) +++ trunk/refman-4.1/database-administration.xml 2006-01-21 03:45:12 UTC (rev 963) @@ -6073,7 +6073,7 @@ Increasing this value increases the number of file descriptors that mysqld requires. See , for comments on file - descriptor limits. Also see + descriptor limits. See also . Modified: trunk/refman-4.1/functions.xml =================================================================== --- trunk/refman-4.1/functions.xml 2006-01-21 03:10:02 UTC (rev 962) +++ trunk/refman-4.1/functions.xml 2006-01-21 03:45:12 UTC (rev 963) @@ -7013,7 +7013,7 @@ - Given a daynumber N, returns a + Given a day number N, returns a DATE value. @@ -7838,7 +7838,7 @@ - This is the reverse of the DATE_FORMAT() + This is the inverse of the DATE_FORMAT() function. It takes a string str and a format string format. STR_TO_DATE() returns a @@ -7871,12 +7871,10 @@ str should be given in the format indicated by format. For the specifiers that can be used in - format, see the table in the - DATE_FORMAT() function description. All - other characters are just taken verbatim, thus not being - interpreted. If str contains an - illegal date, time, or datetime value, - STR_TO_DATE() returns + format, see the + DATE_FORMAT() function description. If + str contains an illegal date, time, + or datetime value, STR_TO_DATE() returns NULL. @@ -7971,17 +7969,17 @@ - Note that you cannot use - format "%X%V" to convert a year-week string - to a date as the combination of a year and week does not + Note: You cannot use format + "%X%V" to convert a year-week string to a + date because the combination of a year and week does not uniquely identify a year and month if the week crosses a month boundary. To convert a year-week to a date, then you should also specify the weekday: -mysql> select str_to_date('200442 Monday', '%X%V %W'); --> 2004-10-18 +mysql> SELECT STR_TO_DATE('200442 Monday', '%X%V %W'); + -> '2004-10-18' @@ -8178,7 +8176,7 @@ datetime value. With two arguments, it adds the time expression expr2 to the date or datetime expression expr and - returns theresult as a datetime value. + returns the result as a datetime value. @@ -8217,9 +8215,9 @@ This is used like the DATE_FORMAT() function, but the format string may - contain only those format specifiers that handle hours, - minutes, and seconds. Other specifiers produce a - NULL value or 0. + contain format specifiers only for hours, minutes, and + seconds. Other specifiers produce a NULL + value or 0. @@ -8293,8 +8291,8 @@ - Given a date date, returns a - daynumber (the number of days since year 0). + Given a date date, returns a day + number (the number of days since year 0). @@ -8312,8 +8310,10 @@ TO_DAYS() is not intended for use with values that precede the advent of the Gregorian calendar (1582), because it does not take into account the days that - were lost when the calendar was changed. See - . + were lost when the calendar was changed. For dates before 1582 + (and possibly a later year in other locales), results from + this function are not reliable. See + , for details. @@ -8328,12 +8328,6 @@ mysql> SELECT TO_DAYS('1997-10-07'), TO_DAYS('97-10-07'); -> 729669, 729669 - - - For dates before 1582 (and possibly a later year in other - locales), results from this function are not reliable. See - , for details. - @@ -8725,9 +8719,8 @@ If you would prefer the result to be evaluated with respect to the year that contains the first day of the week for the given - date, you should use 0, - 2, 5, or - 7 as the optional + date, use 0, 2, + 5, or 7 as the optional mode argument. @@ -8802,8 +8795,9 @@ Returns the calendar week of the date as a number in the range - from 1 to 53. It is a - compatibility function that is equivalent to + from 1 to 53. + WEEKOFYEAR() is a compatibility function + that is equivalent to WEEK(date,3). @@ -8841,7 +8835,8 @@ Returns the year for date, in the - range 1000 to 9999. + range 1000 to 9999, or + 0 for the zero date. @@ -8997,7 +8992,7 @@ did not occur at the same time in all countries, and that the later it happened, the more days were lost. For example, in Great Britain, it took place in 1752, when Wednesday September 2 was - followed by Thursday September 14; Russia remained on the Julian + followed by Thursday September 14. Russia remained on the Julian calendar until 1918, losing 13 days in the process, and what is popularly referred to as its October Revolution occurred in November according to the Gregorian calendar. @@ -9059,15 +9054,15 @@ and searching. A full-text index in MySQL is an index of type FULLTEXT. FULLTEXT indexes can be used only with MyISAM - tables; they can be created from CHAR, + tables. They can be created for CHAR, VARCHAR, or TEXT columns - as part of a CREATE TABLE statement or - added later using ALTER TABLE or - CREATE INDEX. For large datasets, it is - much faster to load your data into a table that has no - FULLTEXT index, and then create the index - afterwards, than to load data into a table that has an - existing FULLTEXT index. + with CREATE TABLE or added later using + ALTER TABLE or CREATE + INDEX. For large datasets, it is much faster to load + your data into a table that has no FULLTEXT + index and then create the index afterwards, than to load data + into a table that has an existing FULLTEXT + index. @@ -9117,14 +9112,14 @@ The MATCH() function performs a natural - language search for a string against a text collection. A - collection is a set of one or more columns included in a - FULLTEXT index. The search string is given as - the argument to AGAINST(). For each row in the - table, MATCH() returns a relevance value, that - is, a similarity measure between the search string and the text in - that row in the columns named in the MATCH() - list. + language search for a string against a text + collection. A collection is a set of one or more + columns included in a FULLTEXT index. The + search string is given as the argument to + AGAINST(). For each row in the table, + MATCH() returns a relevance value, that is, a + similarity measure between the search string and the text in that + row in the columns named in the MATCH() list. @@ -9139,13 +9134,13 @@ When MATCH() is used in a - WHERE clause, as in the preceding example, the - rows returned are automatically sorted with the highest relevance - first. Relevance values are non-negative floating-point numbers. - Zero relevance means no similarity. Relevance is computed based on - the number of words in the row, the number of unique words in that - row, the total number of words in the collection, and the number - of documents (rows) that contain a particular word. + WHERE clause, as in the example shown earlier, + the rows returned are automatically sorted with the highest + relevance first. Relevance values are non-negative floating-point + numbers. Zero relevance means no similarity. Relevance is computed + based on the number of words in the row, the number of unique + words in that row, the total number of words in the collection, + and the number of documents (rows) that contain a particular word. @@ -9159,7 +9154,7 @@ article table's FULLTEXT index. If you wanted to search the title or body separately, you would need to create - FULLTEXT indexes for each column. + separate FULLTEXT indexes for each column. @@ -9170,13 +9165,13 @@ - The preceding example is a basic illustration showing how to use - the MATCH() function where rows are returned in - order of decreasing relevance. The next example shows how to - retrieve the relevance values explicitly. Returned rows are not - ordered because the SELECT statement includes - neither WHERE nor ORDER BY - clauses: + The preceding example is a basic illustration that shows how to + use the MATCH() function where rows are + returned in order of decreasing relevance. The next example shows + how to retrieve the relevance values explicitly. Returned rows are + not ordered because the SELECT statement + includes neither WHERE nor ORDER + BY clauses: @@ -9237,15 +9232,16 @@ The FULLTEXT parser determines where words - start and end by looking for certain delimiters, for example - ' ' (the space character), , - (the comma), and . (the period). If words are - not separated by delimiters (as in, for example, Chinese), the + start and end by looking for certain delimiter characters; for + example, ‘ ’ (space), + ‘,’ (comma), and + ‘.’ (period). If words are not + separated by delimiters (as in, for example, Chinese), the FULLTEXT parser cannot determine where a word begins or ends. To be able to add words or other indexed terms in such languages to a FULLTEXT index, you must preprocess them so that they are separated by some arbitrary - delimiter such as ". + delimiter such as ‘"’. @@ -9268,8 +9264,7 @@ such as the or some that is so common that it is considered to have zero semantic value. There is a built-in stopword list, but it can be overwritten - by a user-defined list. See - . + by a user-defined list. @@ -9288,12 +9283,12 @@ Every correct word in the collection and in the query is weighted - according to its significance in the collection or query. This - way, a word that is present in many documents has a lower weight - (and may even have a zero weight), because it has lower semantic - value in this particular collection. Conversely, if the word is - rare, it receives a higher weight. The weights of the words are - then combined to compute the relevance of the row. + according to its significance in the collection or query. + Consequently, a word that is present in many documents has a lower + weight (and may even have a zero weight), because it has lower + semantic value in this particular collection. Conversely, if the + word is rare, it receives a higher weight. The weights of the + words are combined to compute the relevance of the row. @@ -9302,8 +9297,8 @@ distribution does not adequately reflect their semantic value, and this model may sometimes produce bizarre results. For example, although the word MySQL is present in every row of - the articles table, a search for the word - produces no results: + the articles table shown earlier, a search for + the word produces no results: @@ -9316,9 +9311,9 @@ The search result is empty because the word MySQL is present in at least 50% of the rows. As such, it is effectively treated as a stopword. For large datasets, this is the most - desirable behavior — a natural language query should not - return every second row from a 1GB table. For small datasets, it - may be less desirable. + desirable behavior: A natural language query should not return + every second row from a 1GB table. For small datasets, it may be + less desirable. @@ -9348,7 +9343,7 @@ &title-fulltext-boolean; - As of version 4.0.1, MySQL can also perform boolean full-text + As of version 4.0.1, MySQL can perform boolean full-text searches using the IN BOOLEAN MODE modifier: @@ -9367,9 +9362,12 @@ - This query retrieves all the rows that contain the word - MySQL but that do not - contain the word YourSQL. + The + and - operators + indicate that a word is required to be present or absent, + respectively, for a match to occur. Thus, this query retrieves + all the rows that contain the word MySQL but that + do not contain the word + YourSQL. @@ -9468,7 +9466,7 @@ - (no operator) + (no operator) @@ -9490,7 +9488,7 @@ to the relevance value that is assigned to a row. The > operator increases the contribution and the < operator decreases it. See - the example below. + the example following this list. @@ -9500,8 +9498,8 @@ - Parentheses are used to group words into subexpressions. - Parenthesized groups can be nested. + Parentheses group words into subexpressions. Parenthesized + groups can be nested. @@ -9526,9 +9524,11 @@ - The asterisk serves as the truncation operator. Unlike the - other operators, it should be appended - to the word to be affected. + The asterisk serves as the truncation (or wildcard) + operator. Unlike the other operators, it should be + appended to the word to be affected. + Words match if they begin with the word preceding the + * operator. @@ -9662,9 +9662,9 @@ words (for example, rows that contain some words of wisdom but not some noise words). Note that the - ‘"’ characters that surround + ‘"’ characters that enclose the phrase are operator characters that delimit the phrase. - They are not the quotes that surround the search string + They are not the quotes that enclose the search string itself. @@ -9682,8 +9682,8 @@ particular, its variant blind query expansion). This is generally useful when a search phrase is too short, which often means that the user is relying on implied knowledge - that the full-text search engine usually lacks. For example, a - user searching for database may really mean that + that the full-text search engine lacks. For example, a user + searching for database may really mean that MySQL, Oracle, DB2, and RDBMS all are phrases that should match databases and should be returned, too. This is @@ -9696,12 +9696,13 @@ EXPANSION following the search phrase. It works by performing the search twice, where the search phrase for the second search is the original search phrase concatenated with - the few top found documents from the first search. Thus, if one - of these documents contains the word databases - and the word MySQL, the second search finds the - documents that contain the word MySQL even if - they do not contain the word database. The - following example shows this difference: + the few most highly relevant documents from the first search. + Thus, if one of these documents contains the word + databases and the word MySQL, the + second search finds the documents that contain the word + MySQL even if they do not contain the word + database. The following example shows this + difference: @@ -10550,7 +10551,7 @@ As of MySQL 4.1.1, full-text searches can be used with most multi-byte character sets. The exception is that for - Unicode; the utf8 character set can be + Unicode, the utf8 character set can be used, but not the ucs2 character set. @@ -10582,7 +10583,8 @@ exactly the column list in some FULLTEXT index definition for the table, unless this MATCH() is IN BOOLEAN - MODE. + MODE. Boolean-mode searches can be done on + non-indexed columns, although they are likely to be slow. @@ -10612,14 +10614,14 @@ Note that full-text search is carefully tuned for the most effectiveness. Modifying the default behavior in most cases can - actually decrease it. Do not alter the MySQL sources - unless you know what you are doing. + actually decrease effectiveness. Do not alter the + MySQL sources unless you know what you are doing. - Most full-text variables described below must be set at server - startup time. A server restart is required to change them; they - cannot be modified while the server is running. + Most full-text variables described in this section must be set + at server startup time. A server restart is required to change + them; they cannot be modified while the server is running. @@ -10632,18 +10634,17 @@ - The minimum and maximum length of words to be indexed is + The minimum and maximum lengths of words to be indexed are defined by the ft_min_word_len and ft_max_word_len system variables (available as of MySQL 4.0.0). See .) The default - minimum value is four characters; the default maximum - depends on the MySQL version in use. If you change either - value, you must rebuild your FULLTEXT - indexes. For example, if you want three-character words to - be searchable, you can set the - ft_min_word_len variable by putting the - following lines in an option file: + minimum value is four characters; the default maximum is + version dependent. If you change either value, you must + rebuild your FULLTEXT indexes. For + example, if you want three-character words to be searchable, + you can set the ft_min_word_len variable + by putting the following lines in an option file: @@ -10652,9 +10653,9 @@ - Then restart the server and rebuild your - FULLTEXT indexes. Also note particularly - the remarks regarding myisamchk in the + Then you must restart the server and rebuild your + FULLTEXT indexes. Note particularly the + remarks regarding myisamchk in the instructions following this list. @@ -10678,8 +10679,8 @@ value should be the pathname of the file containing the stopword list, or the empty string to disable stopword filtering. After changing the value of this variable or the - contents of the stopword file, rebuild your - FULLTEXT indexes. + contents of the stopword file, restart the server and + rebuild your FULLTEXT indexes. @@ -10716,12 +10717,12 @@ Then recompile MySQL. There is no need to rebuild the indexes in this case. Note: - By doing this you severely decrease - MySQL's ability to provide adequate relevance values for the - MATCH() function. If you really need to - search for such common words, it would be better to search - using IN BOOLEAN MODE instead, which does - not observe the 50% threshold. + By making this change, you severely + decrease MySQL's ability to provide adequate relevance + values for the MATCH() function. If you + really need to search for such common words, it would be + better to search using IN BOOLEAN MODE + instead, which does not observe the 50% threshold. @@ -10729,8 +10730,8 @@ To change the operators used for boolean full-text searches, set the ft_boolean_syntax system variable - (available as of MySQL 4.0.1). The variable also can be - changed while the server is running, but you must have the + (available as of MySQL 4.0.1). The variable can be changed + while the server is running, but you must have the SUPER privilege to do so. No rebuilding of indexes is necessary in this case. See , which describes @@ -10780,17 +10781,18 @@ Note that if you use myisamchk to perform an operation that modifies table indexes (such as repair or analyze), the FULLTEXT indexes are rebuilt - using the default full-text parameter values for minimum and - maximum word length and the stopword file unless you specify - otherwise. This can result in queries failing. + using the default full-text parameter + values for minimum word length, maximum word length, and + stopword file unless you specify otherwise. This can result in + queries failing. The problem occurs because these parameters are known only by the server. They are not stored in MyISAM index files. To avoid the problem if you have modified the - minimum or maximum word length or the stopword file in the - server, specify the same ft_min_word_len, + minimum or maximum word length or stopword file values used by + the server, specify the same ft_min_word_len, ft_max_word_len, and ft_stopword_file values to myisamchk that you use for @@ -10805,8 +10807,8 @@ To ensure that myisamchk and the server use - the same values for full-text parameters, you can place each one - in both the [mysqld] and + the same values for full-text parameters, place each one in both + the [mysqld] and [myisamchk] sections of an option file: @@ -10822,9 +10824,9 @@ An alternative to using myisamchk is to use the REPAIR TABLE, ANALYZE TABLE, OPTIMIZE TABLE, or - ALTER TABLE. These statements are performed - by the server, which knows the proper full-text parameter values - to use. + ALTER TABLE statements. These statements are + performed by the server, which knows the proper full-text + parameter values to use. Modified: trunk/refman-4.1/innodb.xml =================================================================== --- trunk/refman-4.1/innodb.xml 2006-01-21 03:10:02 UTC (rev 962) +++ trunk/refman-4.1/innodb.xml 2006-01-21 03:45:12 UTC (rev 963) @@ -1275,9 +1275,9 @@ work regardless of the value. Note that many operating systems and some disk hardware fool the flush-to-disk operation. They may tell mysqld that the flush has taken - place, though it has not. Then the durability of transactions - is not guaranteed even with the setting 1, and in the worst - case a power outage can even corrupt the + place, even though it has not. Then the durability of + transactions is not guaranteed even with the setting 1, and in + the worst case a power outage can even corrupt the InnoDB database. Using a battery-backed disk cache in the SCSI disk controller or in the disk itself speeds up file flushes, and makes the operation safer. You can Modified: trunk/refman-5.0/connector-odbc.xml =================================================================== --- trunk/refman-5.0/connector-odbc.xml 2006-01-21 03:10:02 UTC (rev 962) +++ trunk/refman-5.0/connector-odbc.xml 2006-01-21 03:45:12 UTC (rev 963) @@ -2098,12 +2098,12 @@ &title-data-source-name; - A data source is a place where data comes from. The data - source must have a persistent identifier, the Data Source Name. - Using the Data Source Name, MySQL can access initialization - information. With the initialization information, MySQL knows - where to access the database and what settings to use when the - access starts. + A data source is a place where data comes + from. The data source must have a persistent identifier, the + Data Source Name. Using the Data Source Name, MySQL can access + initialization information. With the initialization information, + MySQL knows where to access the database and what settings to + use when the access starts. @@ -2126,13 +2126,15 @@ If the information is in the Windows registry, it is called a - Machine data source. It might be a User data source, in - which case only one user can see it. Or it might be a System - data source in which case it is accessible to all users on the - computer, or indeed to all users connected to the computer, if - the users are connected by Microsoft Windows NT services. When - you run the ODBC Data Administration program, you have a choice - whether to use "User" or "System" -- there are separate tabs. + Machine data source. It might be a + User data source, in which case only one + user can see it. Or it might be a System data + source in which case it is accessible to all users + on the computer, or indeed to all users connected to the + computer, if the users are connected by Microsoft Windows NT + services. When you run the ODBC Data Administration program, you + have a choice whether to use "User" or "System" -- there are + separate tabs. @@ -4139,8 +4141,8 @@ Tested with BDE 3.0. The only known problem is that when the table schema changes, query fields are not updated. BDE, however, does not seem to recognize primary keys, only the - index named PRIMARY, though this has not - been a problem. + index named PRIMARY, although this has + not been a problem. @@ -4216,7 +4218,7 @@ Enterprise 2000 to MySQL via MyODBC (2.50.37 or greater) and using Visio's reverse engineer function to retrieve information about the DB (Visio shows all the column - definitions, primary keys, Indexes and so on). Also we + definitions, primary keys, indexes and so on). Also, we tested by designing new tables in Visio and exported them to MySQL via MyODBC. Modified: trunk/refman-5.0/database-administration.xml =================================================================== --- trunk/refman-5.0/database-administration.xml 2006-01-21 03:10:02 UTC (rev 962) +++ trunk/refman-5.0/database-administration.xml 2006-01-21 03:45:12 UTC (rev 963) @@ -7547,7 +7547,7 @@ Increasing this value increases the number of file descriptors that mysqld requires. See , for comments on file - descriptor limits. Also see + descriptor limits. See also . @@ -23350,8 +23350,8 @@ server is started with binlog-do-db=sales, and you do USE prices; UPDATE sales.january SET - amount=amount+1000;, this statement - is not written into the binary log. + amount=amount+1000;, this statement is + not written into the binary log. @@ -23373,8 +23373,8 @@ server is started with binlog-ignore-db=sales, and you do USE prices; UPDATE sales.january SET - amount=amount+1000;, this statement is written - into the binary log. + amount=amount+1000;, this statement + is written into the binary log. Modified: trunk/refman-5.0/functions.xml =================================================================== --- trunk/refman-5.0/functions.xml 2006-01-21 03:10:02 UTC (rev 962) +++ trunk/refman-5.0/functions.xml 2006-01-21 03:45:12 UTC (rev 963) @@ -7088,7 +7088,7 @@ - Given a daynumber N, returns a + Given a day number N, returns a DATE value. @@ -7696,7 +7696,8 @@ Within a stored routine or trigger, NOW() returns a constant time that indicates the time at which the routine or triggering statement began to execute. This differs - from the behavior for SYSDATE(). + from the behavior for SYSDATE(), which + returns the exact time at which it executes. @@ -7894,7 +7895,7 @@ - This is the reverse of the DATE_FORMAT() + This is the inverse of the DATE_FORMAT() function. It takes a string str and a format string format. STR_TO_DATE() returns a @@ -7927,12 +7928,10 @@ str should be given in the format indicated by format. For the specifiers that can be used in - format, see the table in the - DATE_FORMAT() function description. All - other characters are just taken verbatim, thus not being - interpreted. If str contains an - illegal date, time, or datetime value, - STR_TO_DATE() returns + format, see the + DATE_FORMAT() function description. If + str contains an illegal date, time, + or datetime value, STR_TO_DATE() returns NULL. Starting from MySQL 5.0.3, an illegal value also produces a warning. @@ -8010,9 +8009,9 @@ The second form allows the use of an integer value for - days. In such cases, it is reckoned - to be the number of days to be subtracted from the date or - datetime expression expr. + days. In such cases, it is + interpreted as the number of days to be subtracted from the + date or datetime expression expr. @@ -8021,17 +8020,17 @@ - Note that you cannot use - format "%X%V" to convert a year-week string - to a date as the combination of a year and week does not + Note: You cannot use format + "%X%V" to convert a year-week string to a + date because the combination of a year and week does not uniquely identify a year and month if the week crosses a month boundary. To convert a year-week to a date, then you should also specify the weekday: -mysql> select str_to_date('200442 Monday', '%X%V %W'); --> 2004-10-18 +mysql> SELECT STR_TO_DATE('200442 Monday', '%X%V %W'); + -> '2004-10-18' @@ -8106,9 +8105,9 @@ Within a stored routine or trigger, SYSDATE() returns the time at which it - executes, not the time at which the routine or triggering - statement began to execute. This differs from the behavior for - NOW(). + executes. This differs from the behavior for + NOW(), which returns the the time at which + the routine or triggering statement began to execute. @@ -8224,7 +8223,7 @@ datetime value. With two arguments, it adds the time expression expr2 to the date or datetime expression expr and - returns theresult as a datetime value. + returns the result as a datetime value. @@ -8273,7 +8272,7 @@ The interval value may be specified using one of keywords as shown, or with a prefix of SQL_TSI_. For example, - DAY or SQL_TSI_DAY both + DAY and SQL_TSI_DAY both are legal. @@ -8359,9 +8358,9 @@ This is used like the DATE_FORMAT() function, but the format string may - contain only those format specifiers that handle hours, - minutes, and seconds. Other specifiers produce a - NULL value or 0. + contain format specifiers only for hours, minutes, and + seconds. Other specifiers produce a NULL + value or 0. @@ -8435,8 +8434,8 @@ - Given a date date, returns a - daynumber (the number of days since year 0). + Given a date date, returns a day + number (the number of days since year 0). @@ -8454,8 +8453,10 @@ TO_DAYS() is not intended for use with values that precede the advent of the Gregorian calendar (1582), because it does not take into account the days that - were lost when the calendar was changed. See - . + were lost when the calendar was changed. For dates before 1582 + (and possibly a later year in other locales), results from + this function are not reliable. See + , for details. @@ -8470,12 +8471,6 @@ mysql> SELECT TO_DAYS('1997-10-07'), TO_DAYS('97-10-07'); -> 729669, 729669 - - - For dates before 1582 (and possibly a later year in other - locales), results from this function are not reliable. See - , for details. - @@ -8832,9 +8827,8 @@ If you would prefer the result to be evaluated with respect to the year that contains the first day of the week for the given - date, you should use 0, - 2, 5, or - 7 as the optional + date, use 0, 2, + 5, or 7 as the optional mode argument. @@ -8909,8 +8903,9 @@ Returns the calendar week of the date as a number in the range - from 1 to 53. It is a - compatibility function that is equivalent to + from 1 to 53. + WEEKOFYEAR() is a compatibility function + that is equivalent to WEEK(date,3). @@ -8943,7 +8938,8 @@ Returns the year for date, in the - range 1000 to 9999. + range 1000 to 9999, or + 0 for the zero date. @@ -9095,7 +9091,7 @@ did not occur at the same time in all countries, and that the later it happened, the more days were lost. For example, in Great Britain, it took place in 1752, when Wednesday September 2 was - followed by Thursday September 14; Russia remained on the Julian + followed by Thursday September 14. Russia remained on the Julian calendar until 1918, losing 13 days in the process, and what is popularly referred to as its October Revolution occurred in November according to the Gregorian calendar. @@ -9157,15 +9153,15 @@ full-text index in MySQL is an index of type FULLTEXT. FULLTEXT indexes can be used only with MyISAM - tables; they can be created from CHAR, + tables. They can be created for CHAR, VARCHAR, or TEXT columns - as part of a CREATE TABLE statement or - added later using ALTER TABLE or - CREATE INDEX. For large datasets, it is - much faster to load your data into a table that has no - FULLTEXT index, and then create the index - afterwards, than to load data into a table that has an - existing FULLTEXT index. + with CREATE TABLE or added later using + ALTER TABLE or CREATE + INDEX. For large datasets, it is much faster to load + your data into a table that has no FULLTEXT + index and then create the index afterwards, than to load data + into a table that has an existing FULLTEXT + index. @@ -9215,14 +9211,14 @@ The MATCH() function performs a natural - language search for a string against a text collection. A - collection is a set of one or more columns included in a - FULLTEXT index. The search string is given as - the argument to AGAINST(). For each row in the - table, MATCH() returns a relevance value, that - is, a similarity measure between the search string and the text in - that row in the columns named in the MATCH() - list. + language search for a string against a text + collection. A collection is a set of one or more + columns included in a FULLTEXT index. The + search string is given as the argument to + AGAINST(). For each row in the table, + MATCH() returns a relevance value, that is, a + similarity measure between the search string and the text in that + row in the columns named in the MATCH() list. @@ -9236,13 +9232,13 @@ When MATCH() is used in a - WHERE clause, as in the preceding example, the - rows returned are automatically sorted with the highest relevance - first. Relevance values are non-negative floating-point numbers. - Zero relevance means no similarity. Relevance is computed based on - the number of words in the row, the number of unique words in that - row, the total number of words in the collection, and the number - of documents (rows) that contain a particular word. + WHERE clause, as in the example shown earlier, + the rows returned are automatically sorted with the highest + relevance first. Relevance values are non-negative floating-point + numbers. Zero relevance means no similarity. Relevance is computed + based on the number of words in the row, the number of unique + words in that row, the total number of words in the collection, + and the number of documents (rows) that contain a particular word. @@ -9256,7 +9252,7 @@ article table's FULLTEXT index. If you wanted to search the title or body separately, you would need to create - FULLTEXT indexes for each column. + separate FULLTEXT indexes for each column. @@ -9267,13 +9263,13 @@ - The preceding example is a basic illustration showing how to use - the MATCH() function where rows are returned in - order of decreasing relevance. The next example shows how to - retrieve the relevance values explicitly. Returned rows are not - ordered because the SELECT statement includes - neither WHERE nor ORDER BY - clauses: + The preceding example is a basic illustration that shows how to + use the MATCH() function where rows are + returned in order of decreasing relevance. The next example shows + how to retrieve the relevance values explicitly. Returned rows are + not ordered because the SELECT statement + includes neither WHERE nor ORDER + BY clauses: @@ -9334,15 +9330,16 @@ The FULLTEXT parser determines where words - start and end by looking for certain delimiters, for example - ' ' (the space character), , - (the comma), and . (the period). If words are - not separated by delimiters (as in, for example, Chinese), the + start and end by looking for certain delimiter characters; for + example, ‘ ’ (space), + ‘,’ (comma), and + ‘.’ (period). If words are not + separated by delimiters (as in, for example, Chinese), the FULLTEXT parser cannot determine where a word begins or ends. To be able to add words or other indexed terms in such languages to a FULLTEXT index, you must preprocess them so that they are separated by some arbitrary - delimiter such as ". + delimiter such as ‘"’. @@ -9365,8 +9362,7 @@ such as the or some that is so common that it is considered to have zero semantic value. There is a built-in stopword list, but it can be overwritten - by a user-defined list. See - . + by a user-defined list. @@ -9385,12 +9381,12 @@ Every correct word in the collection and in the query is weighted - according to its significance in the collection or query. This - way, a word that is present in many documents has a lower weight - (and may even have a zero weight), because it has lower semantic - value in this particular collection. Conversely, if the word is - rare, it receives a higher weight. The weights of the words are - then combined to compute the relevance of the row. + according to its significance in the collection or query. + Consequently, a word that is present in many documents has a lower + weight (and may even have a zero weight), because it has lower + semantic value in this particular collection. Conversely, if the + word is rare, it receives a higher weight. The weights of the + words are combined to compute the relevance of the row. @@ -9399,8 +9395,8 @@ distribution does not adequately reflect their semantic value, and this model may sometimes produce bizarre results. For example, although the word MySQL is present in every row of - the articles table, a search for the word - produces no results: + the articles table shown earlier, a search for + the word produces no results: @@ -9413,9 +9409,9 @@ The search result is empty because the word MySQL is present in at least 50% of the rows. As such, it is effectively treated as a stopword. For large datasets, this is the most - desirable behavior — a natural language query should not - return every second row from a 1GB table. For small datasets, it - may be less desirable. + desirable behavior: A natural language query should not return + every second row from a 1GB table. For small datasets, it may be + less desirable. @@ -9445,7 +9441,7 @@ &title-fulltext-boolean; - MySQL can also perform boolean full-text searches using the + MySQL can perform boolean full-text searches using the IN BOOLEAN MODE modifier: @@ -9464,9 +9460,12 @@ - This query retrieves all the rows that contain the word - MySQL but that do not - contain the word YourSQL. + The + and - operators + indicate that a word is required to be present or absent, + respectively, for a match to occur. Thus, this query retrieves + all the rows that contain the word MySQL but that + do not contain the word + YourSQL. @@ -9565,7 +9564,7 @@ - (no operator) + (no operator) @@ -9587,7 +9586,7 @@ to the relevance value that is assigned to a row. The > operator increases the contribution and the < operator decreases it. See - the example below. + the example following this list. @@ -9597,8 +9596,8 @@ - Parentheses are used to group words into subexpressions. - Parenthesized groups can be nested. + Parentheses group words into subexpressions. Parenthesized + groups can be nested. @@ -9623,9 +9622,11 @@ - The asterisk serves as the truncation operator. Unlike the - other operators, it should be appended - to the word to be affected. + The asterisk serves as the truncation (or wildcard) + operator. Unlike the other operators, it should be + appended to the word to be affected. + Words match if they begin with the word preceding the + * operator. @@ -9763,9 +9764,9 @@ words (for example, rows that contain some words of wisdom but not some noise words). Note that the - ‘"’ characters that surround + ‘"’ characters that enclose the phrase are operator characters that delimit the phrase. - They are not the quotes that surround the search string + They are not the quotes that enclose the search string itself. @@ -9783,8 +9784,8 @@ its variant blind query expansion). This is generally useful when a search phrase is too short, which often means that the user is relying on implied knowledge that the - full-text search engine usually lacks. For example, a user - searching for database may really mean that + full-text search engine lacks. For example, a user searching for + database may really mean that MySQL, Oracle, DB2, and RDBMS all are phrases that should match databases and should be returned, too. This is @@ -9797,12 +9798,13 @@ EXPANSION following the search phrase. It works by performing the search twice, where the search phrase for the second search is the original search phrase concatenated with - the few top found documents from the first search. Thus, if one - of these documents contains the word databases - and the word MySQL, the second search finds the - documents that contain the word MySQL even if - they do not contain the word database. The - following example shows this difference: + the few most highly relevant documents from the first search. + Thus, if one of these documents contains the word + databases and the word MySQL, the + second search finds the documents that contain the word + MySQL even if they do not contain the word + database. The following example shows this + difference: @@ -10650,7 +10652,7 @@ Full-text searches can be used with most multi-byte - character sets. The exception is that for Unicode; the + character sets. The exception is that for Unicode, the utf8 character set can be used, but not the ucs2 character set. @@ -10683,7 +10685,8 @@ exactly the column list in some FULLTEXT index definition for the table, unless this MATCH() is IN BOOLEAN - MODE. + MODE. Boolean-mode searches can be done on + non-indexed columns, although they are likely to be slow. @@ -10713,14 +10716,14 @@ Note that full-text search is carefully tuned for the most effectiveness. Modifying the default behavior in most cases can - actually decrease it. Do not alter the MySQL sources - unless you know what you are doing. + actually decrease effectiveness. Do not alter the + MySQL sources unless you know what you are doing. - Most full-text variables described below must be set at server - startup time. A server restart is required to change them; they - cannot be modified while the server is running. + Most full-text variables described in this section must be set + at server startup time. A server restart is required to change + them; they cannot be modified while the server is running. @@ -10733,17 +10736,16 @@ - The minimum and maximum length of words to be indexed is + The minimum and maximum lengths of words to be indexed are defined by the ft_min_word_len and ft_max_word_len system variables. (See .) The default - minimum value is four characters; the default maximum - depends on the MySQL version in use. If you change either - value, you must rebuild your FULLTEXT - indexes. For example, if you want three-character words to - be searchable, you can set the - ft_min_word_len variable by putting the - following lines in an option file: + minimum value is four characters; the default maximum is + version dependent. If you change either value, you must + rebuild your FULLTEXT indexes. For + example, if you want three-character words to be searchable, + you can set the ft_min_word_len variable + by putting the following lines in an option file: @@ -10752,9 +10754,9 @@ - Then restart the server and rebuild your - FULLTEXT indexes. Also note particularly - the remarks regarding myisamchk in the + Then you must restart the server and rebuild your + FULLTEXT indexes. Note particularly the + remarks regarding myisamchk in the instructions following this list. @@ -10777,8 +10779,8 @@ value should be the pathname of the file containing the stopword list, or the empty string to disable stopword filtering. After changing the value of this variable or the - contents of the stopword file, rebuild your - FULLTEXT indexes. + contents of the stopword file, restart the server and + rebuild your FULLTEXT indexes. @@ -10815,12 +10817,12 @@ Then recompile MySQL. There is no need to rebuild the indexes in this case. Note: - By doing this you severely decrease - MySQL's ability to provide adequate relevance values for the - MATCH() function. If you really need to - search for such common words, it would be better to search - using IN BOOLEAN MODE instead, which does - not observe the 50% threshold. + By making this change, you severely + decrease MySQL's ability to provide adequate relevance + values for the MATCH() function. If you + really need to search for such common words, it would be + better to search using IN BOOLEAN MODE + instead, which does not observe the 50% threshold. @@ -10828,8 +10830,8 @@ To change the operators used for boolean full-text searches, set the ft_boolean_syntax system - variable. This variable also can be changed while the server - is running, but you must have the SUPER + variable. This variable can be changed while the server is + running, but you must have the SUPER privilege to do so. No rebuilding of indexes is necessary in this case. See , which describes the rules governing how to set this @@ -10858,17 +10860,18 @@ Note that if you use myisamchk to perform an operation that modifies table indexes (such as repair or analyze), the FULLTEXT indexes are rebuilt - using the default full-text parameter values for minimum and - maximum word length and the stopword file unless you specify - otherwise. This can result in queries failing. + using the default full-text parameter + values for minimum word length, maximum word length, and + stopword file unless you specify otherwise. This can result in + queries failing. The problem occurs because these parameters are known only by the server. They are not stored in MyISAM index files. To avoid the problem if you have modified the - minimum or maximum word length or the stopword file in the - server, specify the same ft_min_word_len, + minimum or maximum word length or stopword file values used by + the server, specify the same ft_min_word_len, ft_max_word_len, and ft_stopword_file values to myisamchk that you use for @@ -10883,8 +10886,8 @@ To ensure that myisamchk and the server use - the same values for full-text parameters, you can place each one - in both the [mysqld] and + the same values for full-text parameters, place each one in both + the [mysqld] and [myisamchk] sections of an option file: @@ -10900,9 +10903,9 @@ An alternative to using myisamchk is to use the REPAIR TABLE, ANALYZE TABLE, OPTIMIZE TABLE, or - ALTER TABLE. These statements are performed - by the server, which knows the proper full-text parameter values - to use. + ALTER TABLE statements. These statements are + performed by the server, which knows the proper full-text + parameter values to use. Modified: trunk/refman-5.0/information-schema.xml =================================================================== --- trunk/refman-5.0/information-schema.xml 2006-01-21 03:10:02 UTC (rev 962) +++ trunk/refman-5.0/information-schema.xml 2006-01-21 03:45:12 UTC (rev 963) @@ -194,8 +194,8 @@ In effect, we have a new database named - INFORMATION_SCHEMA, though there is never a need - to make a file by that name. It is possible to select + INFORMATION_SCHEMA, although there is never a + need to make a file by that name. It is possible to select INFORMATION_SCHEMA as the default database with a USE statement, but the only way to access the contents of its tables is with SELECT. You cannot Modified: trunk/refman-5.0/innodb.xml =================================================================== --- trunk/refman-5.0/innodb.xml 2006-01-21 03:10:02 UTC (rev 962) +++ trunk/refman-5.0/innodb.xml 2006-01-21 03:45:12 UTC (rev 963) @@ -1220,9 +1220,9 @@ work regardless of the value. Note that many operating systems and some disk hardware fool the flush-to-disk operation. They may tell mysqld that the flush has taken - place, though it has not. Then the durability of transactions - is not guaranteed even with the setting 1, and in the worst - case a power outage can even corrupt the + place, even though it has not. Then the durability of + transactions is not guaranteed even with the setting 1, and in + the worst case a power outage can even corrupt the InnoDB database. Using a battery-backed disk cache in the SCSI disk controller or in the disk itself speeds up file flushes, and makes the operation safer. You can Modified: trunk/refman-5.0/storage-engines.xml =================================================================== --- trunk/refman-5.0/storage-engines.xml 2006-01-21 03:10:02 UTC (rev 962) +++ trunk/refman-5.0/storage-engines.xml 2006-01-21 03:45:12 UTC (rev 963) @@ -3465,7 +3465,7 @@ very simple. Normally, you have two servers running, either both on the same host or on different hosts. (It is possible for a FEDERATED table to use another table that is - managed by the same server, though there is little point in + managed by the same server, although there is little point in doing so.) Modified: trunk/refman-5.1/connector-odbc.xml =================================================================== --- trunk/refman-5.1/connector-odbc.xml 2006-01-21 03:10:02 UTC (rev 962) +++ trunk/refman-5.1/connector-odbc.xml 2006-01-21 03:45:12 UTC (rev 963) @@ -2098,12 +2098,12 @@ &title-data-source-name; - A data source is a place where data comes from. The data - source must have a persistent identifier, the Data Source Name. - Using the Data Source Name, MySQL can access initialization - information. With the initialization information, MySQL knows - where to access the database and what settings to use when the - access starts. + A data source is a place where data comes + from. The data source must have a persistent identifier, the + Data Source Name. Using the Data Source Name, MySQL can access + initialization information. With the initialization information, + MySQL knows where to access the database and what settings to + use when the access starts. @@ -2126,13 +2126,15 @@ If the information is in the Windows registry, it is called a - Machine data source. It might be a User data source, in - which case only one user can see it. Or it might be a System - data source in which case it is accessible to all users on the - computer, or indeed to all users connected to the computer, if - the users are connected by Microsoft Windows NT services. When - you run the ODBC Data Administration program, you have a choice - whether to use "User" or "System" -- there are separate tabs. + Machine data source. It might be a + User data source, in which case only one + user can see it. Or it might be a System data + source in which case it is accessible to all users + on the computer, or indeed to all users connected to the + computer, if the users are connected by Microsoft Windows NT + services. When you run the ODBC Data Administration program, you + have a choice whether to use "User" or "System" -- there are + separate tabs. @@ -4139,8 +4141,8 @@ Tested with BDE 3.0. The only known problem is that when the table schema changes, query fields are not updated. BDE, however, does not seem to recognize primary keys, only the - index named PRIMARY, though this has not - been a problem. + index named PRIMARY, although this has + not been a problem. @@ -4216,7 +4218,7 @@ Enterprise 2000 to MySQL via MyODBC (2.50.37 or greater) and using Visio's reverse engineer function to retrieve information about the DB (Visio shows all the column - definitions, primary keys, Indexes and so on). Also we + definitions, primary keys, indexes and so on). Also, we tested by designing new tables in Visio and exported them to MySQL via MyODBC. Modified: trunk/refman-5.1/database-administration.xml =================================================================== --- trunk/refman-5.1/database-administration.xml 2006-01-21 03:10:02 UTC (rev 962) +++ trunk/refman-5.1/database-administration.xml 2006-01-21 03:45:12 UTC (rev 963) @@ -7546,7 +7546,7 @@ Increasing this value increases the number of file descriptors that mysqld requires. See , for comments on file - descriptor limits. Also see + descriptor limits. See also . Modified: trunk/refman-5.1/functions.xml =================================================================== --- trunk/refman-5.1/functions.xml 2006-01-21 03:10:02 UTC (rev 962) +++ trunk/refman-5.1/functions.xml 2006-01-21 03:45:12 UTC (rev 963) @@ -7042,7 +7042,7 @@ - Given a daynumber N, returns a + Given a day number N, returns a DATE value. @@ -7650,7 +7650,8 @@ Within a stored routine or trigger, NOW() returns a constant time that indicates the time at which the routine or triggering statement began to execute. This differs - from the behavior for SYSDATE(). + from the behavior for SYSDATE(), which + returns the exact time at which it executes. @@ -7848,7 +7849,7 @@ - This is the reverse of the DATE_FORMAT() + This is the inverse of the DATE_FORMAT() function. It takes a string str and a format string format. STR_TO_DATE() returns a @@ -7881,12 +7882,10 @@ str should be given in the format indicated by format. For the specifiers that can be used in - format, see the table in the - DATE_FORMAT() function description. All - other characters are just taken verbatim, thus not being - interpreted. If str contains an - illegal date, time, or datetime value, - STR_TO_DATE() returns + format, see the + DATE_FORMAT() function description. If + str contains an illegal date, time, + or datetime value, STR_TO_DATE() returns NULL. An illegal value also produces a warning. @@ -7964,9 +7963,9 @@ The second form allows the use of an integer value for - days. In such cases, it is reckoned - to be the number of days to be subtracted from the date or - datetime expression expr. + days. In such cases, it is + interpreted as the number of days to be subtracted from the + date or datetime expression expr. @@ -7975,17 +7974,17 @@ - Note that you cannot use - format "%X%V" to convert a year-week string - to a date as the combination of a year and week does not + Note: You cannot use format + "%X%V" to convert a year-week string to a + date because the combination of a year and week does not uniquely identify a year and month if the week crosses a month boundary. To convert a year-week to a date, then you should also specify the weekday: -mysql> select str_to_date('200442 Monday', '%X%V %W'); --> 2004-10-18 +mysql> SELECT STR_TO_DATE('200442 Monday', '%X%V %W'); + -> '2004-10-18' @@ -8060,9 +8059,9 @@ Within a stored routine or trigger, SYSDATE() returns the time at which it - executes, not the time at which the routine or triggering - statement began to execute. This differs from the behavior for - NOW(). + executes. This differs from the behavior for + NOW(), which returns the the time at which + the routine or triggering statement began to execute. @@ -8178,7 +8177,7 @@ datetime value. With two arguments, it adds the time expression expr2 to the date or datetime expression expr and - returns theresult as a datetime value. + returns the result as a datetime value. @@ -8227,7 +8226,7 @@ The interval value may be specified using one of keywords as shown, or with a prefix of SQL_TSI_. For example, - DAY or SQL_TSI_DAY both + DAY and SQL_TSI_DAY both are legal. @@ -8303,9 +8302,9 @@ This is used like the DATE_FORMAT() function, but the format string may - contain only those format specifiers that handle hours, - minutes, and seconds. Other specifiers produce a - NULL value or 0. + contain format specifiers only for hours, minutes, and + seconds. Other specifiers produce a NULL + value or 0. @@ -8379,8 +8378,8 @@ - Given a date date, returns a - daynumber (the number of days since year 0). + Given a date date, returns a day + number (the number of days since year 0). @@ -8398,8 +8397,10 @@ TO_DAYS() is not intended for use with values that precede the advent of the Gregorian calendar (1582), because it does not take into account the days that - were lost when the calendar was changed. See - . + were lost when the calendar was changed. For dates before 1582 + (and possibly a later year in other locales), results from + this function are not reliable. See + , for details. @@ -8414,12 +8415,6 @@ mysql> SELECT TO_DAYS('1997-10-07'), TO_DAYS('97-10-07'); -> 729669, 729669 - - - For dates before 1582 (and possibly a later year in other - locales), results from this function are not reliable. See - , for details. - @@ -8776,9 +8771,8 @@ If you would prefer the result to be evaluated with respect to the year that contains the first day of the week for the given - date, you should use 0, - 2, 5, or - 7 as the optional + date, use 0, 2, + 5, or 7 as the optional mode argument. @@ -8853,8 +8847,9 @@ Returns the calendar week of the date as a number in the range - from 1 to 53. It is a - compatibility function that is equivalent to + from 1 to 53. + WEEKOFYEAR() is a compatibility function + that is equivalent to WEEK(date,3). @@ -8887,7 +8882,8 @@ Returns the year for date, in the - range 1000 to 9999. + range 1000 to 9999, or + 0 for the zero date. @@ -9039,7 +9035,7 @@ did not occur at the same time in all countries, and that the later it happened, the more days were lost. For example, in Great Britain, it took place in 1752, when Wednesday September 2 was - followed by Thursday September 14; Russia remained on the Julian + followed by Thursday September 14. Russia remained on the Julian calendar until 1918, losing 13 days in the process, and what is popularly referred to as its October Revolution occurred in November according to the Gregorian calendar. @@ -9101,15 +9097,15 @@ full-text index in MySQL is an index of type FULLTEXT. FULLTEXT indexes can be used only with MyISAM - tables; they can be created from CHAR, + tables. They can be created for CHAR, VARCHAR, or TEXT columns - as part of a CREATE TABLE statement or - added later using ALTER TABLE or - CREATE INDEX. For large datasets, it is - much faster to load your data into a table that has no - FULLTEXT index, and then create the index - afterwards, than to load data into a table that has an - existing FULLTEXT index. + with CREATE TABLE or added later using + ALTER TABLE or CREATE + INDEX. For large datasets, it is much faster to load + your data into a table that has no FULLTEXT + index and then create the index afterwards, than to load data + into a table that has an existing FULLTEXT + index. @@ -9159,14 +9155,14 @@ The MATCH() function performs a natural - language search for a string against a text collection. A - collection is a set of one or more columns included in a - FULLTEXT index. The search string is given as - the argument to AGAINST(). For each row in the - table, MATCH() returns a relevance value, that - is, a similarity measure between the search string and the text in - that row in the columns named in the MATCH() - list. + language search for a string against a text + collection. A collection is a set of one or more + columns included in a FULLTEXT index. The + search string is given as the argument to + AGAINST(). For each row in the table, + MATCH() returns a relevance value, that is, a + similarity measure between the search string and the text in that + row in the columns named in the MATCH() list. @@ -9180,13 +9176,13 @@ When MATCH() is used in a - WHERE clause, as in the preceding example, the - rows returned are automatically sorted with the highest relevance - first. Relevance values are non-negative floating-point numbers. - Zero relevance means no similarity. Relevance is computed based on - the number of words in the row, the number of unique words in that - row, the total number of words in the collection, and the number - of documents (rows) that contain a particular word. + WHERE clause, as in the example shown earlier, + the rows returned are automatically sorted with the highest + relevance first. Relevance values are non-negative floating-point + numbers. Zero relevance means no similarity. Relevance is computed + based on the number of words in the row, the number of unique + words in that row, the total number of words in the collection, + and the number of documents (rows) that contain a particular word. @@ -9200,7 +9196,7 @@ article table's FULLTEXT index. If you wanted to search the title or body separately, you would need to create - FULLTEXT indexes for each column. + separate FULLTEXT indexes for each column. @@ -9211,13 +9207,13 @@ - The preceding example is a basic illustration showing how to use - the MATCH() function where rows are returned in - order of decreasing relevance. The next example shows how to - retrieve the relevance values explicitly. Returned rows are not - ordered because the SELECT statement includes - neither WHERE nor ORDER BY - clauses: + The preceding example is a basic illustration that shows how to + use the MATCH() function where rows are + returned in order of decreasing relevance. The next example shows + how to retrieve the relevance values explicitly. Returned rows are + not ordered because the SELECT statement + includes neither WHERE nor ORDER + BY clauses: @@ -9278,15 +9274,16 @@ The FULLTEXT parser determines where words - start and end by looking for certain delimiters, for example - ' ' (the space character), , - (the comma), and . (the period). If words are - not separated by delimiters (as in, for example, Chinese), the + start and end by looking for certain delimiter characters; for + example, ‘ ’ (space), + ‘,’ (comma), and + ‘.’ (period). If words are not + separated by delimiters (as in, for example, Chinese), the FULLTEXT parser cannot determine where a word begins or ends. To be able to add words or other indexed terms in such languages to a FULLTEXT index, you must preprocess them so that they are separated by some arbitrary - delimiter such as ". + delimiter such as ‘"’. @@ -9317,8 +9314,7 @@ such as the or some that is so common that it is considered to have zero semantic value. There is a built-in stopword list, but it can be overwritten - by a user-defined list. See - . + by a user-defined list. @@ -9337,12 +9333,12 @@ Every correct word in the collection and in the query is weighted - according to its significance in the collection or query. This - way, a word that is present in many documents has a lower weight - (and may even have a zero weight), because it has lower semantic - value in this particular collection. Conversely, if the word is - rare, it receives a higher weight. The weights of the words are - then combined to compute the relevance of the row. + according to its significance in the collection or query. + Consequently, a word that is present in many documents has a lower + weight (and may even have a zero weight), because it has lower + semantic value in this particular collection. Conversely, if the + word is rare, it receives a higher weight. The weights of the + words are combined to compute the relevance of the row. @@ -9351,8 +9347,8 @@ distribution does not adequately reflect their semantic value, and this model may sometimes produce bizarre results. For example, although the word MySQL is present in every row of - the articles table, a search for the word - produces no results: + the articles table shown earlier, a search for + the word produces no results: @@ -9365,9 +9361,9 @@ The search result is empty because the word MySQL is present in at least 50% of the rows. As such, it is effectively treated as a stopword. For large datasets, this is the most - desirable behavior — a natural language query should not - return every second row from a 1GB table. For small datasets, it - may be less desirable. + desirable behavior: A natural language query should not return + every second row from a 1GB table. For small datasets, it may be + less desirable. @@ -9397,7 +9393,7 @@ &title-fulltext-boolean; - MySQL can also perform boolean full-text searches using the + MySQL can perform boolean full-text searches using the IN BOOLEAN MODE modifier: @@ -9416,9 +9412,12 @@ - This query retrieves all the rows that contain the word - MySQL but that do not - contain the word YourSQL. + The + and - operators + indicate that a word is required to be present or absent, + respectively, for a match to occur. Thus, this query retrieves + all the rows that contain the word MySQL but that + do not contain the word + YourSQL. @@ -9517,7 +9516,7 @@ - (no operator) + (no operator) @@ -9539,7 +9538,7 @@ to the relevance value that is assigned to a row. The > operator increases the contribution and the < operator decreases it. See - the example below. + the example following this list. @@ -9549,8 +9548,8 @@ - Parentheses are used to group words into subexpressions. - Parenthesized groups can be nested. + Parentheses group words into subexpressions. Parenthesized + groups can be nested. @@ -9575,9 +9574,11 @@ - The asterisk serves as the truncation operator. Unlike the - other operators, it should be appended - to the word to be affected. + The asterisk serves as the truncation (or wildcard) + operator. Unlike the other operators, it should be + appended to the word to be affected. + Words match if they begin with the word preceding the + * operator. @@ -9711,9 +9712,9 @@ words (for example, rows that contain some words of wisdom but not some noise words). Note that the - ‘"’ characters that surround + ‘"’ characters that enclose the phrase are operator characters that delimit the phrase. - They are not the quotes that surround the search string + They are not the quotes that enclose the search string itself. @@ -9731,8 +9732,8 @@ its variant blind query expansion). This is generally useful when a search phrase is too short, which often means that the user is relying on implied knowledge that the - full-text search engine usually lacks. For example, a user - searching for database may really mean that + full-text search engine lacks. For example, a user searching for + database may really mean that MySQL, Oracle, DB2, and RDBMS all are phrases that should match databases and should be returned, too. This is @@ -9745,12 +9746,13 @@ EXPANSION following the search phrase. It works by performing the search twice, where the search phrase for the second search is the original search phrase concatenated with - the few top found documents from the first search. Thus, if one - of these documents contains the word databases - and the word MySQL, the second search finds the - documents that contain the word MySQL even if - they do not contain the word database. The - following example shows this difference: + the few most highly relevant documents from the first search. + Thus, if one of these documents contains the word + databases and the word MySQL, the + second search finds the documents that contain the word + MySQL even if they do not contain the word + database. The following example shows this + difference: @@ -10598,7 +10600,7 @@ Full-text searches can be used with most multi-byte - character sets. The exception is that for Unicode; the + character sets. The exception is that for Unicode, the utf8 character set can be used, but not the ucs2 character set. @@ -10631,7 +10633,8 @@ exactly the column list in some FULLTEXT index definition for the table, unless this MATCH() is IN BOOLEAN - MODE. + MODE. Boolean-mode searches can be done on + non-indexed columns, although they are likely to be slow. @@ -10661,14 +10664,14 @@ Note that full-text search is carefully tuned for the most effectiveness. Modifying the default behavior in most cases can - actually decrease it. Do not alter the MySQL sources - unless you know what you are doing. + actually decrease effectiveness. Do not alter the + MySQL sources unless you know what you are doing. - Most full-text variables described below must be set at server - startup time. A server restart is required to change them; they - cannot be modified while the server is running. + Most full-text variables described in this section must be set + at server startup time. A server restart is required to change + them; they cannot be modified while the server is running. @@ -10681,17 +10684,16 @@ - The minimum and maximum length of words to be indexed is + The minimum and maximum lengths of words to be indexed are defined by the ft_min_word_len and ft_max_word_len system variables. (See .) The default - minimum value is four characters; the default maximum - depends on the MySQL version in use. If you change either - value, you must rebuild your FULLTEXT - indexes. For example, if you want three-character words to - be searchable, you can set the - ft_min_word_len variable by putting the - following lines in an option file: + minimum value is four characters; the default maximum is + version dependent. If you change either value, you must + rebuild your FULLTEXT indexes. For + example, if you want three-character words to be searchable, + you can set the ft_min_word_len variable + by putting the following lines in an option file: @@ -10700,9 +10702,9 @@ - Then restart the server and rebuild your - FULLTEXT indexes. Also note particularly - the remarks regarding myisamchk in the + Then you must restart the server and rebuild your + FULLTEXT indexes. Note particularly the + remarks regarding myisamchk in the instructions following this list. @@ -10725,8 +10727,8 @@ value should be the pathname of the file containing the stopword list, or the empty string to disable stopword filtering. After changing the value of this variable or the - contents of the stopword file, rebuild your - FULLTEXT indexes. + contents of the stopword file, restart the server and + rebuild your FULLTEXT indexes. @@ -10763,12 +10765,12 @@ Then recompile MySQL. There is no need to rebuild the indexes in this case. Note: - By doing this you severely decrease - MySQL's ability to provide adequate relevance values for the - MATCH() function. If you really need to - search for such common words, it would be better to search - using IN BOOLEAN MODE instead, which does - not observe the 50% threshold. + By making this change, you severely + decrease MySQL's ability to provide adequate relevance + values for the MATCH() function. If you + really need to search for such common words, it would be + better to search using IN BOOLEAN MODE + instead, which does not observe the 50% threshold. @@ -10776,8 +10778,8 @@ To change the operators used for boolean full-text searches, set the ft_boolean_syntax system - variable. This variable also can be changed while the server - is running, but you must have the SUPER + variable. This variable can be changed while the server is + running, but you must have the SUPER privilege to do so. No rebuilding of indexes is necessary in this case. See , which describes the rules governing how to set this @@ -10806,17 +10808,18 @@ Note that if you use myisamchk to perform an operation that modifies table indexes (such as repair or analyze), the FULLTEXT indexes are rebuilt - using the default full-text parameter values for minimum and - maximum word length and the stopword file unless you specify - otherwise. This can result in queries failing. + using the default full-text parameter + values for minimum word length, maximum word length, and + stopword file unless you specify otherwise. This can result in + queries failing. The problem occurs because these parameters are known only by the server. They are not stored in MyISAM index files. To avoid the problem if you have modified the - minimum or maximum word length or the stopword file in the - server, specify the same ft_min_word_len, + minimum or maximum word length or stopword file values used by + the server, specify the same ft_min_word_len, ft_max_word_len, and ft_stopword_file values to myisamchk that you use for @@ -10831,8 +10834,8 @@ To ensure that myisamchk and the server use - the same values for full-text parameters, you can place each one - in both the [mysqld] and + the same values for full-text parameters, place each one in both + the [mysqld] and [myisamchk] sections of an option file: @@ -10848,9 +10851,9 @@ An alternative to using myisamchk is to use the REPAIR TABLE, ANALYZE TABLE, OPTIMIZE TABLE, or - ALTER TABLE. These statements are performed - by the server, which knows the proper full-text parameter values - to use. + ALTER TABLE statements. These statements are + performed by the server, which knows the proper full-text + parameter values to use. Modified: trunk/refman-5.1/information-schema.xml =================================================================== --- trunk/refman-5.1/information-schema.xml 2006-01-21 03:10:02 UTC (rev 962) +++ trunk/refman-5.1/information-schema.xml 2006-01-21 03:45:12 UTC (rev 963) @@ -194,8 +194,8 @@ In effect, we have a new database named - INFORMATION_SCHEMA, though there is never a need - to make a file by that name. It is possible to select + INFORMATION_SCHEMA, although there is never a + need to make a file by that name. It is possible to select INFORMATION_SCHEMA as the default database with a USE statement, but the only way to access the contents of its tables is with SELECT. You cannot Modified: trunk/refman-5.1/innodb.xml =================================================================== --- trunk/refman-5.1/innodb.xml 2006-01-21 03:10:02 UTC (rev 962) +++ trunk/refman-5.1/innodb.xml 2006-01-21 03:45:12 UTC (rev 963) @@ -1216,9 +1216,9 @@ work regardless of the value. Note that many operating systems and some disk hardware fool the flush-to-disk operation. They may tell mysqld that the flush has taken - place, though it has not. Then the durability of transactions - is not guaranteed even with the setting 1, and in the worst - case a power outage can even corrupt the + place, even though it has not. Then the durability of + transactions is not guaranteed even with the setting 1, and in + the worst case a power outage can even corrupt the InnoDB database. Using a battery-backed disk cache in the SCSI disk controller or in the disk itself speeds up file flushes, and makes the operation safer. You can Modified: trunk/refman-5.1/storage-engines.xml =================================================================== --- trunk/refman-5.1/storage-engines.xml 2006-01-21 03:10:02 UTC (rev 962) +++ trunk/refman-5.1/storage-engines.xml 2006-01-21 03:45:12 UTC (rev 963) @@ -250,7 +250,7 @@ - @@ -3466,7 +3466,7 @@ very simple. Normally, you have two servers running, either both on the same host or on different hosts. (It is possible for a FEDERATED table to use another table that is - managed by the same server, though there is little point in + managed by the same server, although there is little point in doing so.)