List:Commits« Previous MessageNext Message »
From:paul Date:January 19 2006 5:47pm
Subject:svn commit - mysqldoc@docsrva: r932 - in trunk: . refman-4.1 refman-5.0 refman-5.1
View as plain text  
Author: paul
Date: 2006-01-19 18:47:24 +0100 (Thu, 19 Jan 2006)
New Revision: 932

Log:
 r6436@frost:  paul | 2006-01-19 10:51:34 -0600
 General revisions.


Modified:
   trunk/
   trunk/refman-4.1/data-types.xml
   trunk/refman-5.0/client-utility-programs.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:6434
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2335
   + b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6436
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2335

Modified: trunk/refman-4.1/data-types.xml
===================================================================
--- trunk/refman-4.1/data-types.xml	2006-01-19 15:53:07 UTC (rev 931)
+++ trunk/refman-4.1/data-types.xml	2006-01-19 17:47:24 UTC (rev 932)
@@ -3861,16 +3861,6 @@
       </para>
 
       <para>
-        If a <literal>CHAR</literal> or <literal>VARCHAR</literal>
-        column is indexed, index entry comparisons are space-padded at
-        the end. This means that, if the index requires unique values,
-        duplicate-key errors will occur for values that differ only in
-        the number of trailing spaces. For example, inserting
-        <literal>'a'</literal> and <literal>'a '</literal> causes a
-        duplicate-key error.
-      </para>
-
-      <para>
         If you assign a value to a <literal>CHAR</literal> or
         <literal>VARCHAR</literal> column that exceeds the column's
         maximum length, the value is truncated to fit. If the truncated
@@ -3945,10 +3935,10 @@
       </informaltable>
 
       <para>
-        The values retrieved from the <literal>CHAR(4)</literal> and
-        <literal>VARCHAR(4)</literal> columns are the same in each case,
-        because trailing spaces are removed from <literal>CHAR</literal>
-        columns upon retrieval.
+        If a given value is stored into the <literal>CHAR(4)</literal>
+        and <literal>VARCHAR(4)</literal> columns, the values retrieved
+        from the columns are not always the same because trailing spaces
+        are removed from <literal>CHAR</literal> columns upon retrieval.
       </para>
 
       <para>
@@ -3999,6 +3989,16 @@
       </para>
 
       <para>
+        For those cases where trailing pad characters are stripped or
+        comparisons ignore them, if a column has an index that requires
+        unique values, inserting into the column values that differ only
+        in number of trailing pad characters will result in a
+        duplicate-key error. For example, if a table contains
+        <literal>'a'</literal>, an attempt to store
+        <literal>'a&nbsp;'</literal> causes a duplicate-key error.
+      </para>
+
+      <para>
         The <literal>BINARY</literal> attribute is sticky. This means
         that if a column marked <literal>BINARY</literal> is used in an
         expression, the whole expression is treated as a
@@ -4006,24 +4006,6 @@
       </para>
 
       <para>
-        From MySQL 4.1.2 on, the <literal>CHAR BYTE</literal> data type
-        is an alias for the <literal>BINARY</literal> type. This is a
-        compatibility feature.
-      </para>
-
-      <para>
-        From MySQL 4.1.0 on, the <literal>ASCII</literal> attribute can
-        be specified for <literal>CHAR</literal>. It assigns the
-        <literal>latin1</literal> character set.
-      </para>
-
-      <para>
-        From MySQL 4.1.1 on, the <literal>UNICODE</literal> attribute
-        can be specified for <literal>CHAR</literal>. It assigns the
-        <literal>ucs2</literal> character set.
-      </para>
-
-      <para>
         MySQL may silently change the type of a <literal>CHAR</literal>
         or <literal>VARCHAR</literal> column at table creation time. See
         <xref linkend="silent-column-changes"/>.
@@ -4060,7 +4042,7 @@
         strings rather than non-binary strings. That is, they contain
         byte strings rather than character strings. This means that they
         have no character set, and sorting and comparison are based on
-        the numeric values of the bytes in column values.
+        the numeric values of the bytes in the values.
       </para>
 
       <para>

Modified: trunk/refman-5.0/client-utility-programs.xml
===================================================================
--- trunk/refman-5.0/client-utility-programs.xml	2006-01-19 15:53:07 UTC (rev 931)
+++ trunk/refman-5.0/client-utility-programs.xml	2006-01-19 17:47:24 UTC (rev 932)
@@ -2550,7 +2550,6 @@
 use       (\u) Use another database. Takes database name as argument.
 warnings  (\W) Show warnings after every statement.
 nowarning (\w) Don't show warnings after every statement.
-
 </programlisting>
 
         <para>

Modified: trunk/refman-5.0/data-types.xml
===================================================================
--- trunk/refman-5.0/data-types.xml	2006-01-19 15:53:07 UTC (rev 931)
+++ trunk/refman-5.0/data-types.xml	2006-01-19 17:47:24 UTC (rev 932)
@@ -3525,8 +3525,7 @@
         can be any value from 0 to 255. When <literal>CHAR</literal>
         values are stored, they are right-padded with spaces to the
         specified length. When <literal>CHAR</literal> values are
-        retrieved, trailing spaces are removed. No lettercase conversion
-        takes place during storage or retrieval.
+        retrieved, trailing spaces are removed.
       </para>
 
       <para>
@@ -3558,16 +3557,6 @@
       </para>
 
       <para>
-        If a <literal>CHAR</literal> or <literal>VARCHAR</literal>
-        column is indexed, index entry comparisons are space-padded at
-        the end. This means that, if the index requires unique values,
-        duplicate-key errors will occur for values that differ only in
-        the number of trailing spaces. For example, inserting
-        <literal>'a'</literal> and <literal>'a '</literal> causes a
-        duplicate-key error.
-      </para>
-
-      <para>
         If you assign a value to a <literal>CHAR</literal> or
         <literal>VARCHAR</literal> column that exceeds the column's
         maximum length, the value is truncated to fit. If the truncated
@@ -3659,27 +3648,31 @@
       </para>
 
       <para>
-        The values retrieved from the <literal>CHAR(4)</literal> and
-        <literal>VARCHAR(4)</literal> columns are not always the same,
-        because trailing spaces are removed from <literal>CHAR</literal>
-        columns upon retrieval. This difference is illustrated by the
-        following example:
+        If a given value is stored into the <literal>CHAR(4)</literal>
+        and <literal>VARCHAR(4)</literal> columns, the values retrieved
+        from the columns are not always the same because trailing spaces
+        are removed from <literal>CHAR</literal> columns upon retrieval.
+        The following example illustrates this difference:
       </para>
 
 <programlisting>
+<!--
+mysql> DROP TABLE IF EXISTS vc;
+Query OK, 0 rows affected, 1 warning (0.05 sec)
+-->
 mysql&gt; <userinput>CREATE TABLE vc (v VARCHAR(4), c CHAR(4));</userinput>
-Query OK, 0 rows affected (0.02 sec)
+Query OK, 0 rows affected (0.01 sec)
 
 mysql&gt; <userinput>INSERT INTO vc VALUES ('ab  ', 'ab  ');</userinput>
 Query OK, 1 row affected (0.00 sec)
 
-mysql&gt; <userinput>SELECT CONCAT(v, '+'), CONCAT(c, '+') FROM vc;</userinput>
-+----------------+----------------+
-| CONCAT(v, '+') | CONCAT(c, '+') |
-+----------------+----------------+
-| ab  +          | ab+            |
-+----------------+----------------+
-1 row in set (0.00 sec)
+mysql&gt; <userinput>SELECT CONCAT('(', v, ')'), CONCAT('(', c, ')') FROM vc;</userinput>
++---------------------+---------------------+
+| CONCAT('(', v, ')') | CONCAT('(', c, ')') |
++---------------------+---------------------+
+| (ab  )              | (ab)                |
++---------------------+---------------------+
+1 row in set (0.06 sec)
 </programlisting>
 
       <para>
@@ -3728,21 +3721,11 @@
         comparisons ignore them, if a column has an index that requires
         unique values, inserting into the column values that differ only
         in number of trailing pad characters will result in a
-        duplicate-key error.
+        duplicate-key error. For example, if a table contains
+        <literal>'a'</literal>, an attempt to store
+        <literal>'a&nbsp;'</literal> causes a duplicate-key error.
       </para>
 
-      <para>
-        The <literal>CHAR BYTE</literal> data type is an alias for the
-        <literal>BINARY</literal> type. This is a compatibility feature.
-      </para>
-
-      <para>
-        The <literal>ASCII</literal> attribute assigns the
-        <literal>latin1</literal> character set to a
-        <literal>CHAR</literal> column. The <literal>UNICODE</literal>
-        attribute assigns the <literal>ucs2</literal> character set.
-      </para>
-
     </section>
 
     <section id="binary-varbinary">
@@ -3774,7 +3757,7 @@
         strings rather than non-binary strings. That is, they contain
         byte strings rather than character strings. This means that they
         have no character set, and sorting and comparison are based on
-        the numeric values of the bytes in column values.
+        the numeric values of the bytes in the values.
       </para>
 
       <para>
@@ -3794,7 +3777,7 @@
         the column to be treated as a binary string column. Instead, it
         causes the binary collation for the column character set to be
         used, and the column itself contains non-binary character
-        strings rather than binary byte strings. For example
+        strings rather than binary byte strings. For example,
         <literal>CHAR(5) BINARY</literal> is treated as <literal>CHAR(5)
         CHARACTER SET latin1 COLLATE latin1_bin</literal>, assuming that
         the default character set is <literal>latin1</literal>. This
@@ -3873,7 +3856,9 @@
         comparisons ignore them, if a column has an index that requires
         unique values, inserting into the column values that differ only
         in number of trailing pad bytes will result in a duplicate-key
-        error.
+        error. For example, if a table contains <literal>'a'</literal>,
+        an attempt to store <literal>'a\0'</literal> causes a
+        duplicate-key error.
       </para>
 
       <para>

Modified: trunk/refman-5.1/data-types.xml
===================================================================
--- trunk/refman-5.1/data-types.xml	2006-01-19 15:53:07 UTC (rev 931)
+++ trunk/refman-5.1/data-types.xml	2006-01-19 17:47:24 UTC (rev 932)
@@ -3417,8 +3417,7 @@
         can be any value from 0 to 255. When <literal>CHAR</literal>
         values are stored, they are right-padded with spaces to the
         specified length. When <literal>CHAR</literal> values are
-        retrieved, trailing spaces are removed. No lettercase conversion
-        takes place during storage or retrieval.
+        retrieved, trailing spaces are removed.
       </para>
 
       <para>
@@ -3445,16 +3444,6 @@
       </para>
 
       <para>
-        If a <literal>CHAR</literal> or <literal>VARCHAR</literal>
-        column is indexed, index entry comparisons are space-padded at
-        the end. This means that, if the index requires unique values,
-        duplicate-key errors will occur for values that differ only in
-        the number of trailing spaces. For example, inserting
-        <literal>'a'</literal> and <literal>'a '</literal> causes a
-        duplicate-key error.
-      </para>
-
-      <para>
         If you assign a value to a <literal>CHAR</literal> or
         <literal>VARCHAR</literal> column that exceeds the column's
         maximum length, the value is truncated to fit. If the truncated
@@ -3534,27 +3523,31 @@
       </para>
 
       <para>
-        The values retrieved from the <literal>CHAR(4)</literal> and
-        <literal>VARCHAR(4)</literal> columns are not always the same,
-        because trailing spaces are removed from <literal>CHAR</literal>
-        columns upon retrieval. This difference is illustrated by the
-        following example:
+        If a given value is stored into the <literal>CHAR(4)</literal>
+        and <literal>VARCHAR(4)</literal> columns, the values retrieved
+        from the columns are not always the same because trailing spaces
+        are removed from <literal>CHAR</literal> columns upon retrieval.
+        The following example illustrates this difference:
       </para>
 
 <programlisting>
+<!--
+mysql> DROP TABLE IF EXISTS vc;
+Query OK, 0 rows affected, 1 warning (0.05 sec)
+-->
 mysql&gt; <userinput>CREATE TABLE vc (v VARCHAR(4), c CHAR(4));</userinput>
-Query OK, 0 rows affected (0.02 sec)
+Query OK, 0 rows affected (0.01 sec)
 
 mysql&gt; <userinput>INSERT INTO vc VALUES ('ab  ', 'ab  ');</userinput>
 Query OK, 1 row affected (0.00 sec)
 
-mysql&gt; <userinput>SELECT CONCAT(v, '+'), CONCAT(c, '+') FROM vc;</userinput>
-+----------------+----------------+
-| CONCAT(v, '+') | CONCAT(c, '+') |
-+----------------+----------------+
-| ab  +          | ab+            |
-+----------------+----------------+
-1 row in set (0.00 sec)
+mysql&gt; <userinput>SELECT CONCAT('(', v, ')'), CONCAT('(', c, ')') FROM vc;</userinput>
++---------------------+---------------------+
+| CONCAT('(', v, ')') | CONCAT('(', c, ')') |
++---------------------+---------------------+
+| (ab  )              | (ab)                |
++---------------------+---------------------+
+1 row in set (0.06 sec)
 </programlisting>
 
       <para>
@@ -3601,21 +3594,10 @@
         comparisons ignore them, if a column has an index that requires
         unique values, inserting into the column values that differ only
         in number of trailing pad characters will result in a
-        duplicate-key error.
+        duplicate-key error. For example, if a table contains
+        <literal>'a'</literal>, an attempt to store <literal>'a&nbsp;'</literal> causes a duplicate-key error.
       </para>
 
-      <para>
-        The <literal>CHAR BYTE</literal> data type is an alias for the
-        <literal>BINARY</literal> type. This is a compatibility feature.
-      </para>
-
-      <para>
-        The <literal>ASCII</literal> attribute assigns the
-        <literal>latin1</literal> character set to a
-        <literal>CHAR</literal> column. The <literal>UNICODE</literal>
-        attribute assigns the <literal>ucs2</literal> character set.
-      </para>
-
     </section>
 
     <section id="binary-varbinary">
@@ -3647,7 +3629,7 @@
         strings rather than non-binary strings. That is, they contain
         byte strings rather than character strings. This means that they
         have no character set, and sorting and comparison are based on
-        the numeric values of the bytes in column values.
+        the numeric values of the bytes in the values.
       </para>
 
       <para>
@@ -3667,7 +3649,7 @@
         the column to be treated as a binary string column. Instead, it
         causes the binary collation for the column character set to be
         used, and the column itself contains non-binary character
-        strings rather than binary byte strings. For example
+        strings rather than binary byte strings. For example,
         <literal>CHAR(5) BINARY</literal> is treated as <literal>CHAR(5)
         CHARACTER SET latin1 COLLATE latin1_bin</literal>, assuming that
         the default character set is <literal>latin1</literal>. This
@@ -3710,6 +3692,8 @@
         unique values, inserting into the column values that differ only
         in number of trailing pad bytes will result in a duplicate-key
         error.
+        For example, if a table contains
+        <literal>'a'</literal>, an attempt to store <literal>'a\0'</literal> causes a duplicate-key error.
       </para>
 
       <para>

Thread
svn commit - mysqldoc@docsrva: r932 - in trunk: . refman-4.1 refman-5.0 refman-5.1paul19 Jan