Author: paul
Date: 2008-10-02 20:29:33 +0200 (Thu, 02 Oct 2008)
New Revision: 11955
Log:
r34413@frost: paul | 2008-10-02 13:21:19 -0500
Add section describing some diffs between _bin collations and binary collation
(info from Bar)
Modified:
trunk/refman-4.1/internationalization.xml
trunk/refman-5.0/internationalization.xml
trunk/refman-5.0/manual.xml
trunk/refman-5.1/internationalization.xml
trunk/refman-5.1/manual.xml
trunk/refman-6.0/internationalization.xml
trunk/refman-6.0/manual.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:35828
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:34409
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:33554
+ 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:35828
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:34413
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:33554
Modified: trunk/refman-4.1/internationalization.xml
===================================================================
--- trunk/refman-4.1/internationalization.xml 2008-10-02 17:32:26 UTC (rev 11954)
+++ trunk/refman-4.1/internationalization.xml 2008-10-02 18:29:33 UTC (rev 11955)
Changed blocks: 1, Lines Added: 178, Lines Deleted: 0; 6468 bytes
@@ -1955,6 +1955,184 @@
</section>
+ <section id="charset-binary-collations">
+
+ <title>The <literal>_bin</literal> and <literal>binary</literal> Collations</title>
+
+ <para>
+ This section describes how <literal>_bin</literal> collations
+ differ from the <literal>binary</literal> collation.
+ </para>
+
+ <para>
+ Non-binary strings (as stored in the <literal>CHAR</literal>,
+ <literal>VARCHAR</literal>, and <literal>TEXT</literal> data
+ types) have a character set and collation. A given character
+ set can have several collations, each of which defines a
+ particular sorting and comparison order for the characters in
+ the set. One of this is the binary collation for the character
+ set, indicated by a <literal>_bin</literal> suffix in the
+ collation name. For example, <literal>latin1</literal> and
+ <literal>utf8</literal> have binary collations named
+ <literal>latin1_bin</literal> and <literal>utf8_bin</literal>.
+ </para>
+
+ <para>
+ Binary strings (as stored in the <literal>BINARY</literal>,
+ <literal>VARBINARY</literal>, and <literal>BLOB</literal> data
+ types) have no character set or collation. Applied to a binary
+ string, the <literal>CHARSET()</literal> and
+ <literal>COLLATION()</literal> functions return a value of
+ <literal>binary</literal>.
+ </para>
+
+ <para>
+ The <literal>_bin</literal> collations differ from the
+ <literal>binary</literal> collation in several respects.
+ </para>
+
+ <para>
+ <emphasis role="bold">The unit for sorting and
+ comparison.</emphasis> Binary strings are sequences of bytes.
+ Sorting and comparison is always based on numeric byte values.
+ Non-binary strings are sequences of characters, which might be
+ multi-byte. For their collations, including the
+ <literal>_bin</literal> collation, sorting and comparison is
+ based numeric character values.
+ </para>
+
+ <para>
+ <emphasis role="bold">Character set conversion.</emphasis> A
+ non-binary string has a character set and is converted to
+ another character set in many cases, even when the string has
+ a <literal>_bin</literal> collation:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ When assigning column values from another column that has
+ a different character set:
+ </para>
+
+<programlisting>
+UPDATE t1 SET utf8_bin_column=latin1_column;
+INSERT INTO t1 (latin1_column) SELECT utf8_bin_column FROM t2;
+</programlisting>
+ </listitem>
+
+ <listitem>
+ <para>
+ When assigning column values for <literal>INSERT</literal>
+ or <literal>UPDATE</literal> using a string literal:
+ </para>
+
+<programlisting>
+SET NAMES latin1;
+INSERT INTO t1 (utf8_bin_column) VALUES ('string-in-latin1');
+</programlisting>
+ </listitem>
+
+ <listitem>
+ <para>
+ When sending results from the server to a client:
+ </para>
+
+<programlisting>
+SET NAMES latin1;
+SELECT utf8_bin_column FROM t2;
+</programlisting>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ For binary string columns, no conversion occurs. For the
+ preceding cases, the string value is copied byte-wise.
+ </para>
+
+ <para>
+ Trailing space handling in comparisons. Non-binary strings
+ have <literal>PADSPACE</literal> behavior for all collations,
+ including <literal>_bin</literal> collations. Trailing spaces
+ are insignificant in comparisons:
+ </para>
+
+<programlisting>
+mysql> <userinput>SET NAMES utf8 COLLATE utf8_bin;</userinput>
+Query OK, 0 rows affected (0.00 sec)
+
+mysql> <userinput>SELECT 'a ' = 'a';</userinput>
++------------+
+| 'a ' = 'a' |
++------------+
+| 1 |
++------------+
+1 row in set (0.00 sec)
+</programlisting>
+
+ <para>
+ For binary strings, all characters are significant in
+ comparisons, including trailing spaces:
+ </para>
+
+<programlisting>
+mysql> <userinput>SET NAMES binary;</userinput>
+Query OK, 0 rows affected (0.00 sec)
+
+mysql> <userinput>SELECT 'a ' = 'a';</userinput>
++------------+
+| 'a ' = 'a' |
++------------+
+| 0 |
++------------+
+1 row in set (0.00 sec)
+</programlisting>
+
+ <para>
+ Trailing space handling for inserts and retrievals.
+ <literal>CHAR(<replaceable>N</replaceable>)</literal> columns
+ store non-binary strings. Values shorter than
+ <replaceable>N</replaceable> characters are extended with
+ spaces on insertion. For retrieval, trailing spaces are
+ removed.
+ </para>
+
+ <para>
+ <literal>BINARY(<replaceable>N</replaceable>)</literal>
+ columns store binary strings. Values shorter than
+ <replaceable>N</replaceable> bytes are extended with
+ <literal>0x00</literal> bytes on insertion. For retrieval,
+ nothing is removed; a value of the declared length is always
+ returned.
+ </para>
+
+<programlisting>
+<!--
+mysql> DROP TABLE IF EXISTS t1;
+Query OK, 0 rows affected (0.11 sec)
+-->
+mysql> <userinput>CREATE TABLE t1 (</userinput>
+ -> <userinput> a CHAR(10) CHARACTER SET utf8 COLLATE utf8_bin,</userinput>
+ -> <userinput> b BINARY(10)</userinput>
+ -> <userinput>);</userinput>
+Query OK, 0 rows affected (0.09 sec)
+
+mysql> <userinput>INSERT INTO t1 VALUES ('a','a');</userinput>
+Query OK, 1 row affected (0.01 sec)
+
+mysql> <userinput>SELECT HEX(a), HEX(b) FROM t1;</userinput>
++--------+----------------------+
+| HEX(a) | HEX(b) |
++--------+----------------------+
+| 61 | 61000000000000000000 |
++--------+----------------------+
+1 row in set (0.04 sec)
+</programlisting>
+
+ </section>
+
<section id="charset-collate-tricky">
<title>Some Special Cases Where the Collation Determination Is Tricky</title>
Modified: trunk/refman-5.0/internationalization.xml
===================================================================
--- trunk/refman-5.0/internationalization.xml 2008-10-02 17:32:26 UTC (rev 11954)
+++ trunk/refman-5.0/internationalization.xml 2008-10-02 18:29:33 UTC (rev 11955)
Changed blocks: 1, Lines Added: 178, Lines Deleted: 0; 6468 bytes
@@ -1973,6 +1973,184 @@
</section>
+ <section id="charset-binary-collations">
+
+ <title>The <literal>_bin</literal> and <literal>binary</literal> Collations</title>
+
+ <para>
+ This section describes how <literal>_bin</literal> collations
+ differ from the <literal>binary</literal> collation.
+ </para>
+
+ <para>
+ Non-binary strings (as stored in the <literal>CHAR</literal>,
+ <literal>VARCHAR</literal>, and <literal>TEXT</literal> data
+ types) have a character set and collation. A given character
+ set can have several collations, each of which defines a
+ particular sorting and comparison order for the characters in
+ the set. One of this is the binary collation for the character
+ set, indicated by a <literal>_bin</literal> suffix in the
+ collation name. For example, <literal>latin1</literal> and
+ <literal>utf8</literal> have binary collations named
+ <literal>latin1_bin</literal> and <literal>utf8_bin</literal>.
+ </para>
+
+ <para>
+ Binary strings (as stored in the <literal>BINARY</literal>,
+ <literal>VARBINARY</literal>, and <literal>BLOB</literal> data
+ types) have no character set or collation. Applied to a binary
+ string, the <literal>CHARSET()</literal> and
+ <literal>COLLATION()</literal> functions return a value of
+ <literal>binary</literal>.
+ </para>
+
+ <para>
+ The <literal>_bin</literal> collations differ from the
+ <literal>binary</literal> collation in several respects.
+ </para>
+
+ <para>
+ <emphasis role="bold">The unit for sorting and
+ comparison.</emphasis> Binary strings are sequences of bytes.
+ Sorting and comparison is always based on numeric byte values.
+ Non-binary strings are sequences of characters, which might be
+ multi-byte. For their collations, including the
+ <literal>_bin</literal> collation, sorting and comparison is
+ based numeric character values.
+ </para>
+
+ <para>
+ <emphasis role="bold">Character set conversion.</emphasis> A
+ non-binary string has a character set and is converted to
+ another character set in many cases, even when the string has
+ a <literal>_bin</literal> collation:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ When assigning column values from another column that has
+ a different character set:
+ </para>
+
+<programlisting>
+UPDATE t1 SET utf8_bin_column=latin1_column;
+INSERT INTO t1 (latin1_column) SELECT utf8_bin_column FROM t2;
+</programlisting>
+ </listitem>
+
+ <listitem>
+ <para>
+ When assigning column values for <literal>INSERT</literal>
+ or <literal>UPDATE</literal> using a string literal:
+ </para>
+
+<programlisting>
+SET NAMES latin1;
+INSERT INTO t1 (utf8_bin_column) VALUES ('string-in-latin1');
+</programlisting>
+ </listitem>
+
+ <listitem>
+ <para>
+ When sending results from the server to a client:
+ </para>
+
+<programlisting>
+SET NAMES latin1;
+SELECT utf8_bin_column FROM t2;
+</programlisting>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ For binary string columns, no conversion occurs. For the
+ preceding cases, the string value is copied byte-wise.
+ </para>
+
+ <para>
+ Trailing space handling in comparisons. Non-binary strings
+ have <literal>PADSPACE</literal> behavior for all collations,
+ including <literal>_bin</literal> collations. Trailing spaces
+ are insignificant in comparisons:
+ </para>
+
+<programlisting>
+mysql> <userinput>SET NAMES utf8 COLLATE utf8_bin;</userinput>
+Query OK, 0 rows affected (0.00 sec)
+
+mysql> <userinput>SELECT 'a ' = 'a';</userinput>
++------------+
+| 'a ' = 'a' |
++------------+
+| 1 |
++------------+
+1 row in set (0.00 sec)
+</programlisting>
+
+ <para>
+ For binary strings, all characters are significant in
+ comparisons, including trailing spaces:
+ </para>
+
+<programlisting>
+mysql> <userinput>SET NAMES binary;</userinput>
+Query OK, 0 rows affected (0.00 sec)
+
+mysql> <userinput>SELECT 'a ' = 'a';</userinput>
++------------+
+| 'a ' = 'a' |
++------------+
+| 0 |
++------------+
+1 row in set (0.00 sec)
+</programlisting>
+
+ <para>
+ Trailing space handling for inserts and retrievals.
+ <literal>CHAR(<replaceable>N</replaceable>)</literal> columns
+ store non-binary strings. Values shorter than
+ <replaceable>N</replaceable> characters are extended with
+ spaces on insertion. For retrieval, trailing spaces are
+ removed.
+ </para>
+
+ <para>
+ <literal>BINARY(<replaceable>N</replaceable>)</literal>
+ columns store binary strings. Values shorter than
+ <replaceable>N</replaceable> bytes are extended with
+ <literal>0x00</literal> bytes on insertion. For retrieval,
+ nothing is removed; a value of the declared length is always
+ returned.
+ </para>
+
+<programlisting>
+<!--
+mysql> DROP TABLE IF EXISTS t1;
+Query OK, 0 rows affected (0.11 sec)
+-->
+mysql> <userinput>CREATE TABLE t1 (</userinput>
+ -> <userinput> a CHAR(10) CHARACTER SET utf8 COLLATE utf8_bin,</userinput>
+ -> <userinput> b BINARY(10)</userinput>
+ -> <userinput>);</userinput>
+Query OK, 0 rows affected (0.09 sec)
+
+mysql> <userinput>INSERT INTO t1 VALUES ('a','a');</userinput>
+Query OK, 1 row affected (0.01 sec)
+
+mysql> <userinput>SELECT HEX(a), HEX(b) FROM t1;</userinput>
++--------+----------------------+
+| HEX(a) | HEX(b) |
++--------+----------------------+
+| 61 | 61000000000000000000 |
++--------+----------------------+
+1 row in set (0.04 sec)
+</programlisting>
+
+ </section>
+
<section id="charset-collate-tricky">
<title>Some Special Cases Where the Collation Determination Is Tricky</title>
Modified: trunk/refman-5.0/manual.xml
===================================================================
Changed blocks: 0, Lines Added: 0, Lines Deleted: 0; 104 bytes
Modified: trunk/refman-5.1/internationalization.xml
===================================================================
--- trunk/refman-5.1/internationalization.xml 2008-10-02 17:32:26 UTC (rev 11954)
+++ trunk/refman-5.1/internationalization.xml 2008-10-02 18:29:33 UTC (rev 11955)
Changed blocks: 1, Lines Added: 178, Lines Deleted: 0; 6468 bytes
@@ -1973,6 +1973,184 @@
</section>
+ <section id="charset-binary-collations">
+
+ <title>The <literal>_bin</literal> and <literal>binary</literal> Collations</title>
+
+ <para>
+ This section describes how <literal>_bin</literal> collations
+ differ from the <literal>binary</literal> collation.
+ </para>
+
+ <para>
+ Non-binary strings (as stored in the <literal>CHAR</literal>,
+ <literal>VARCHAR</literal>, and <literal>TEXT</literal> data
+ types) have a character set and collation. A given character
+ set can have several collations, each of which defines a
+ particular sorting and comparison order for the characters in
+ the set. One of this is the binary collation for the character
+ set, indicated by a <literal>_bin</literal> suffix in the
+ collation name. For example, <literal>latin1</literal> and
+ <literal>utf8</literal> have binary collations named
+ <literal>latin1_bin</literal> and <literal>utf8_bin</literal>.
+ </para>
+
+ <para>
+ Binary strings (as stored in the <literal>BINARY</literal>,
+ <literal>VARBINARY</literal>, and <literal>BLOB</literal> data
+ types) have no character set or collation. Applied to a binary
+ string, the <literal>CHARSET()</literal> and
+ <literal>COLLATION()</literal> functions return a value of
+ <literal>binary</literal>.
+ </para>
+
+ <para>
+ The <literal>_bin</literal> collations differ from the
+ <literal>binary</literal> collation in several respects.
+ </para>
+
+ <para>
+ <emphasis role="bold">The unit for sorting and
+ comparison.</emphasis> Binary strings are sequences of bytes.
+ Sorting and comparison is always based on numeric byte values.
+ Non-binary strings are sequences of characters, which might be
+ multi-byte. For their collations, including the
+ <literal>_bin</literal> collation, sorting and comparison is
+ based numeric character values.
+ </para>
+
+ <para>
+ <emphasis role="bold">Character set conversion.</emphasis> A
+ non-binary string has a character set and is converted to
+ another character set in many cases, even when the string has
+ a <literal>_bin</literal> collation:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ When assigning column values from another column that has
+ a different character set:
+ </para>
+
+<programlisting>
+UPDATE t1 SET utf8_bin_column=latin1_column;
+INSERT INTO t1 (latin1_column) SELECT utf8_bin_column FROM t2;
+</programlisting>
+ </listitem>
+
+ <listitem>
+ <para>
+ When assigning column values for <literal>INSERT</literal>
+ or <literal>UPDATE</literal> using a string literal:
+ </para>
+
+<programlisting>
+SET NAMES latin1;
+INSERT INTO t1 (utf8_bin_column) VALUES ('string-in-latin1');
+</programlisting>
+ </listitem>
+
+ <listitem>
+ <para>
+ When sending results from the server to a client:
+ </para>
+
+<programlisting>
+SET NAMES latin1;
+SELECT utf8_bin_column FROM t2;
+</programlisting>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ For binary string columns, no conversion occurs. For the
+ preceding cases, the string value is copied byte-wise.
+ </para>
+
+ <para>
+ Trailing space handling in comparisons. Non-binary strings
+ have <literal>PADSPACE</literal> behavior for all collations,
+ including <literal>_bin</literal> collations. Trailing spaces
+ are insignificant in comparisons:
+ </para>
+
+<programlisting>
+mysql> <userinput>SET NAMES utf8 COLLATE utf8_bin;</userinput>
+Query OK, 0 rows affected (0.00 sec)
+
+mysql> <userinput>SELECT 'a ' = 'a';</userinput>
++------------+
+| 'a ' = 'a' |
++------------+
+| 1 |
++------------+
+1 row in set (0.00 sec)
+</programlisting>
+
+ <para>
+ For binary strings, all characters are significant in
+ comparisons, including trailing spaces:
+ </para>
+
+<programlisting>
+mysql> <userinput>SET NAMES binary;</userinput>
+Query OK, 0 rows affected (0.00 sec)
+
+mysql> <userinput>SELECT 'a ' = 'a';</userinput>
++------------+
+| 'a ' = 'a' |
++------------+
+| 0 |
++------------+
+1 row in set (0.00 sec)
+</programlisting>
+
+ <para>
+ Trailing space handling for inserts and retrievals.
+ <literal>CHAR(<replaceable>N</replaceable>)</literal> columns
+ store non-binary strings. Values shorter than
+ <replaceable>N</replaceable> characters are extended with
+ spaces on insertion. For retrieval, trailing spaces are
+ removed.
+ </para>
+
+ <para>
+ <literal>BINARY(<replaceable>N</replaceable>)</literal>
+ columns store binary strings. Values shorter than
+ <replaceable>N</replaceable> bytes are extended with
+ <literal>0x00</literal> bytes on insertion. For retrieval,
+ nothing is removed; a value of the declared length is always
+ returned.
+ </para>
+
+<programlisting>
+<!--
+mysql> DROP TABLE IF EXISTS t1;
+Query OK, 0 rows affected (0.11 sec)
+-->
+mysql> <userinput>CREATE TABLE t1 (</userinput>
+ -> <userinput> a CHAR(10) CHARACTER SET utf8 COLLATE utf8_bin,</userinput>
+ -> <userinput> b BINARY(10)</userinput>
+ -> <userinput>);</userinput>
+Query OK, 0 rows affected (0.09 sec)
+
+mysql> <userinput>INSERT INTO t1 VALUES ('a','a');</userinput>
+Query OK, 1 row affected (0.01 sec)
+
+mysql> <userinput>SELECT HEX(a), HEX(b) FROM t1;</userinput>
++--------+----------------------+
+| HEX(a) | HEX(b) |
++--------+----------------------+
+| 61 | 61000000000000000000 |
++--------+----------------------+
+1 row in set (0.04 sec)
+</programlisting>
+
+ </section>
+
<section id="charset-collate-tricky">
<title>Some Special Cases Where the Collation Determination Is Tricky</title>
Modified: trunk/refman-5.1/manual.xml
===================================================================
Changed blocks: 0, Lines Added: 0, Lines Deleted: 0; 104 bytes
Modified: trunk/refman-6.0/internationalization.xml
===================================================================
--- trunk/refman-6.0/internationalization.xml 2008-10-02 17:32:26 UTC (rev 11954)
+++ trunk/refman-6.0/internationalization.xml 2008-10-02 18:29:33 UTC (rev 11955)
Changed blocks: 1, Lines Added: 178, Lines Deleted: 0; 6468 bytes
@@ -1974,6 +1974,184 @@
</section>
+ <section id="charset-binary-collations">
+
+ <title>The <literal>_bin</literal> and <literal>binary</literal> Collations</title>
+
+ <para>
+ This section describes how <literal>_bin</literal> collations
+ differ from the <literal>binary</literal> collation.
+ </para>
+
+ <para>
+ Non-binary strings (as stored in the <literal>CHAR</literal>,
+ <literal>VARCHAR</literal>, and <literal>TEXT</literal> data
+ types) have a character set and collation. A given character
+ set can have several collations, each of which defines a
+ particular sorting and comparison order for the characters in
+ the set. One of this is the binary collation for the character
+ set, indicated by a <literal>_bin</literal> suffix in the
+ collation name. For example, <literal>latin1</literal> and
+ <literal>utf8</literal> have binary collations named
+ <literal>latin1_bin</literal> and <literal>utf8_bin</literal>.
+ </para>
+
+ <para>
+ Binary strings (as stored in the <literal>BINARY</literal>,
+ <literal>VARBINARY</literal>, and <literal>BLOB</literal> data
+ types) have no character set or collation. Applied to a binary
+ string, the <literal>CHARSET()</literal> and
+ <literal>COLLATION()</literal> functions return a value of
+ <literal>binary</literal>.
+ </para>
+
+ <para>
+ The <literal>_bin</literal> collations differ from the
+ <literal>binary</literal> collation in several respects.
+ </para>
+
+ <para>
+ <emphasis role="bold">The unit for sorting and
+ comparison.</emphasis> Binary strings are sequences of bytes.
+ Sorting and comparison is always based on numeric byte values.
+ Non-binary strings are sequences of characters, which might be
+ multi-byte. For their collations, including the
+ <literal>_bin</literal> collation, sorting and comparison is
+ based numeric character values.
+ </para>
+
+ <para>
+ <emphasis role="bold">Character set conversion.</emphasis> A
+ non-binary string has a character set and is converted to
+ another character set in many cases, even when the string has
+ a <literal>_bin</literal> collation:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ When assigning column values from another column that has
+ a different character set:
+ </para>
+
+<programlisting>
+UPDATE t1 SET utf8_bin_column=latin1_column;
+INSERT INTO t1 (latin1_column) SELECT utf8_bin_column FROM t2;
+</programlisting>
+ </listitem>
+
+ <listitem>
+ <para>
+ When assigning column values for <literal>INSERT</literal>
+ or <literal>UPDATE</literal> using a string literal:
+ </para>
+
+<programlisting>
+SET NAMES latin1;
+INSERT INTO t1 (utf8_bin_column) VALUES ('string-in-latin1');
+</programlisting>
+ </listitem>
+
+ <listitem>
+ <para>
+ When sending results from the server to a client:
+ </para>
+
+<programlisting>
+SET NAMES latin1;
+SELECT utf8_bin_column FROM t2;
+</programlisting>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ For binary string columns, no conversion occurs. For the
+ preceding cases, the string value is copied byte-wise.
+ </para>
+
+ <para>
+ Trailing space handling in comparisons. Non-binary strings
+ have <literal>PADSPACE</literal> behavior for all collations,
+ including <literal>_bin</literal> collations. Trailing spaces
+ are insignificant in comparisons:
+ </para>
+
+<programlisting>
+mysql> <userinput>SET NAMES utf8 COLLATE utf8_bin;</userinput>
+Query OK, 0 rows affected (0.00 sec)
+
+mysql> <userinput>SELECT 'a ' = 'a';</userinput>
++------------+
+| 'a ' = 'a' |
++------------+
+| 1 |
++------------+
+1 row in set (0.00 sec)
+</programlisting>
+
+ <para>
+ For binary strings, all characters are significant in
+ comparisons, including trailing spaces:
+ </para>
+
+<programlisting>
+mysql> <userinput>SET NAMES binary;</userinput>
+Query OK, 0 rows affected (0.00 sec)
+
+mysql> <userinput>SELECT 'a ' = 'a';</userinput>
++------------+
+| 'a ' = 'a' |
++------------+
+| 0 |
++------------+
+1 row in set (0.00 sec)
+</programlisting>
+
+ <para>
+ Trailing space handling for inserts and retrievals.
+ <literal>CHAR(<replaceable>N</replaceable>)</literal> columns
+ store non-binary strings. Values shorter than
+ <replaceable>N</replaceable> characters are extended with
+ spaces on insertion. For retrieval, trailing spaces are
+ removed.
+ </para>
+
+ <para>
+ <literal>BINARY(<replaceable>N</replaceable>)</literal>
+ columns store binary strings. Values shorter than
+ <replaceable>N</replaceable> bytes are extended with
+ <literal>0x00</literal> bytes on insertion. For retrieval,
+ nothing is removed; a value of the declared length is always
+ returned.
+ </para>
+
+<programlisting>
+<!--
+mysql> DROP TABLE IF EXISTS t1;
+Query OK, 0 rows affected (0.11 sec)
+-->
+mysql> <userinput>CREATE TABLE t1 (</userinput>
+ -> <userinput> a CHAR(10) CHARACTER SET utf8 COLLATE utf8_bin,</userinput>
+ -> <userinput> b BINARY(10)</userinput>
+ -> <userinput>);</userinput>
+Query OK, 0 rows affected (0.09 sec)
+
+mysql> <userinput>INSERT INTO t1 VALUES ('a','a');</userinput>
+Query OK, 1 row affected (0.01 sec)
+
+mysql> <userinput>SELECT HEX(a), HEX(b) FROM t1;</userinput>
++--------+----------------------+
+| HEX(a) | HEX(b) |
++--------+----------------------+
+| 61 | 61000000000000000000 |
++--------+----------------------+
+1 row in set (0.04 sec)
+</programlisting>
+
+ </section>
+
<section id="charset-collate-tricky">
<title>Some Special Cases Where the Collation Determination Is Tricky</title>
Modified: trunk/refman-6.0/manual.xml
===================================================================
Changed blocks: 0, Lines Added: 0, Lines Deleted: 0; 104 bytes
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r11955 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-6.0 | paul.dubois | 2 Oct |
