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 '</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> <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> <userinput>INSERT INTO vc VALUES ('ab ', 'ab ');</userinput>
Query OK, 1 row affected (0.00 sec)
-mysql> <userinput>SELECT CONCAT(v, '+'), CONCAT(c, '+') FROM vc;</userinput>
-+----------------+----------------+
-| CONCAT(v, '+') | CONCAT(c, '+') |
-+----------------+----------------+
-| ab + | ab+ |
-+----------------+----------------+
-1 row in set (0.00 sec)
+mysql> <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 '</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> <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> <userinput>INSERT INTO vc VALUES ('ab ', 'ab ');</userinput>
Query OK, 1 row affected (0.00 sec)
-mysql> <userinput>SELECT CONCAT(v, '+'), CONCAT(c, '+') FROM vc;</userinput>
-+----------------+----------------+
-| CONCAT(v, '+') | CONCAT(c, '+') |
-+----------------+----------------+
-| ab + | ab+ |
-+----------------+----------------+
-1 row in set (0.00 sec)
+mysql> <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 '</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.1 | paul | 19 Jan |
