| List: | Commits | « Previous MessageNext Message » | |
| From: | paul | Date: | March 24 2006 8:03pm |
| Subject: | svn commit - mysqldoc@docsrva: r1666 - in trunk: . refman-4.1 refman-5.0 refman-5.1 | ||
| View as plain text | |||
Author: paul Date: 2006-03-24 20:03:43 +0100 (Fri, 24 Mar 2006) New Revision: 1666 Log: r4104@kite-hub: paul | 2006-03-24 13:00:18 -0600 Fold in proof corrections. Modified: trunk/ trunk/refman-4.1/data-types.xml trunk/refman-5.0/data-types.xml trunk/refman-5.1/data-types.xml Property changes on: trunk ___________________________________________________________________ Name: svk:merge - b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:8925 bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:4101 + b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:8925 bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:4104 Modified: trunk/refman-4.1/data-types.xml =================================================================== --- trunk/refman-4.1/data-types.xml 2006-03-24 19:03:32 UTC (rev 1665) +++ trunk/refman-4.1/data-types.xml 2006-03-24 19:03:43 UTC (rev 1666) @@ -4252,13 +4252,6 @@ of the <literal>BLOB</literal> data types instead. </para> - <para> - In some cases, MySQL may silently change the type of a - <literal>BINARY</literal> or <literal>VARBINARY</literal> column - at table creation time. See - <xref linkend="silent-column-changes"/>. - </para> - </section> <section id="blob"> @@ -4474,7 +4467,7 @@ you want more than <literal>max_sort_length</literal> bytes to be significant is to convert the column value into a fixed-length object. The standard way to do this is with the - <literal>SUBSTRING</literal> function. For example, the + <literal>SUBSTRING()</literal> function. For example, the following statement causes 2000 bytes of the <literal>comment</literal> column to be taken into account for sorting: Modified: trunk/refman-5.0/data-types.xml =================================================================== --- trunk/refman-5.0/data-types.xml 2006-03-24 19:03:32 UTC (rev 1665) +++ trunk/refman-5.0/data-types.xml 2006-03-24 19:03:43 UTC (rev 1666) @@ -3806,7 +3806,7 @@ <entry><literal>'ab'</literal></entry> <entry><literal>'ab '</literal></entry> <entry>4 bytes</entry> - <entry><literal>'ab '</literal></entry> + <entry><literal>'ab'</literal></entry> <entry>3 bytes</entry> </row> <row> @@ -4040,12 +4040,12 @@ </para> <para> - Note that the <literal>InnoDB</literal> storage engine continues - to preserve trailing spaces in <literal>BINARY</literal> and - <literal>VARBINARY</literal> column values through MySQL 5.0.18, - and then, beginning with MySQL 5.0.19, ignores trailing space - characters in making comparisons as do other MySQL storage - engines. + Note: The <literal>InnoDB</literal> storage engine continues to + preserve trailing spaces in <literal>BINARY</literal> and + <literal>VARBINARY</literal> column values through MySQL 5.0.18. + Beginning with MySQL 5.0.19, <literal>InnoDB</literal> uses + trailing space characters in making comparisons as do other + MySQL storage engines. </para> <para> @@ -4095,13 +4095,6 @@ <literal>BLOB</literal> data types instead. </para> - <para> - In some cases, MySQL may silently change the type of a - <literal>BINARY</literal> or <literal>VARBINARY</literal> column - at table creation time. See - <xref linkend="silent-column-changes"/>. - </para> - </section> <section id="blob"> @@ -4306,7 +4299,7 @@ you want more than <literal>max_sort_length</literal> bytes to be significant is to convert the column value into a fixed-length object. The standard way to do this is with the - <literal>SUBSTRING</literal> function. For example, the + <literal>SUBSTRING()</literal> function. For example, the following statement causes 2000 bytes of the <literal>comment</literal> column to be taken into account for sorting: @@ -5289,13 +5282,13 @@ Note that the number of bytes required per character varies according to the character set used. For example, if a <literal>VARCHAR(100)</literal> column in a Cluster table uses the - <literal>utf-8</literal> character set, then each character + <literal>utf8</literal> character set, then each character requires 3 bytes storage. This means that each record in such a column takes up 100 × 3 + 1 = 301 bytes for storage, regardless of the length of the string actually stored in any given record. For a <literal>VARCHAR(1000)</literal> column in a table using the <literal>NDBCLUSTER</literal> storage engine - with the <literal>utf-8</literal> character set, each record will + with the <literal>utf8</literal> character set, each record will use 1000 × 3 + 2 = 3002 bytes storage; that is, the column is 1,000 characters wide, each character requires 3 bytes storage, and each record has a 2-byte overhead because 1,000 @@ -5385,10 +5378,10 @@ </para> <para> - Calculations on <literal>DECIMAL</literal> values are performed - using double-precision operations. If accuracy is not too - important or if speed is the highest priority, the - <literal>DOUBLE</literal> type may be good enough. For high + Prior to MySQL 5.0.3, calculations on <literal>DECIMAL</literal> + values are performed using double-precision operations. If + accuracy is not too important or if speed is the highest priority, + the <literal>DOUBLE</literal> type may be good enough. For high precision, you can always convert to a fixed-point type stored in a <literal>BIGINT</literal>. This allows you to do all calculations with 64-bit integers and then convert results back to Modified: trunk/refman-5.1/data-types.xml =================================================================== --- trunk/refman-5.1/data-types.xml 2006-03-24 19:03:32 UTC (rev 1665) +++ trunk/refman-5.1/data-types.xml 2006-03-24 19:03:43 UTC (rev 1666) @@ -3666,7 +3666,7 @@ <entry><literal>'ab'</literal></entry> <entry><literal>'ab '</literal></entry> <entry>4 bytes</entry> - <entry><literal>'ab '</literal></entry> + <entry><literal>'ab'</literal></entry> <entry>3 bytes</entry> </row> <row> @@ -4094,7 +4094,7 @@ you want more than <literal>max_sort_length</literal> bytes to be significant is to convert the column value into a fixed-length object. The standard way to do this is with the - <literal>SUBSTRING</literal> function. For example, the + <literal>SUBSTRING()</literal> function. For example, the following statement causes 2000 bytes of the <literal>comment</literal> column to be taken into account for sorting: @@ -5113,12 +5113,10 @@ </para> <para> - Calculations on <literal>DECIMAL</literal> values are performed - using double-precision operations. If accuracy is not too - important or if speed is the highest priority, the - <literal>DOUBLE</literal> type may be good enough. For high - precision, you can always convert to a fixed-point type stored in - a <literal>BIGINT</literal>. This allows you to do all + If accuracy is not too important or if speed is the highest + priority, the <literal>DOUBLE</literal> type may be good enough. + For high precision, you can always convert to a fixed-point type + stored in a <literal>BIGINT</literal>. This allows you to do all calculations with 64-bit integers and then convert results back to floating-point values as necessary. </para>
| Thread | ||
|---|---|---|
| • svn commit - mysqldoc@docsrva: r1666 - in trunk: . refman-4.1 refman-5.0 refman-5.1 | paul | 24 Mar |
© 1995-2008 MySQL AB, 2008-2009 Sun Microsystems, Inc.
Page generated in 0.106 sec. using MySQL 5.1.14-beta-log