Below is the list of changes that have just been committed into a local
mysqldoc repository of paul. When paul does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://www.mysql.com/doc/I/n/Installing_source_tree.html
ChangeSet
1.3138 05/07/26 21:27:51 paul@stripped +3 -0
Kill Texinfo quotes.
refman/charset.xml
1.9 05/07/26 21:27:49 paul@stripped +52 -50
Kill Texinfo quotes.
refman-5.0/charset.xml
1.10 05/07/26 21:27:49 paul@stripped +51 -48
Kill Texinfo quotes.
refman-4.1/charset.xml
1.7 05/07/26 21:27:49 paul@stripped +52 -50
Kill Texinfo quotes.
# This is a BitKeeper patch. What follows are the unified diffs for the
# set of deltas contained in the patch. The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User: paul
# Host: frost.snake.net
# Root: /Volumes/frost2/MySQL/bk/mysqldoc
--- 1.6/refman-4.1/charset.xml 2005-07-19 10:57:14 -05:00
+++ 1.7/refman-4.1/charset.xml 2005-07-26 21:27:49 -05:00
@@ -136,8 +136,8 @@
is less than 1, we say '<literal>A</literal>' is less than
'<literal>B</literal>'. What we've just done is apply a collation
to our character set. The collation is a set of rules (only one
- rule in this case): ``compare the encodings.'' We call this
- simplest of all possible collations a
+ rule in this case): <quote>compare the encodings.</quote> We call
+ this simplest of all possible collations a
<emphasis role="bold">binary</emphasis> collation.
</para>
@@ -158,10 +158,10 @@
with thousands of characters, along with many special symbols and
punctuation marks. Also in real life, most collations have many
rules: not just case insensitivity but also accent insensitivity
- (an ``accent'' is a mark attached to a character as in German
- '<literal>Ö</literal>') and multiple-character mappings (such as
- the rule that '<literal>Ö</literal>' = '<literal>OE</literal>' in
- one of the two German collations).
+ (an <quote>accent</quote> is a mark attached to a character as in
+ German '<literal>Ö</literal>') and multiple-character mappings
+ (such as the rule that '<literal>Ö</literal>' =
+ '<literal>OE</literal>' in one of the two German collations).
</para>
<para>
@@ -251,9 +251,9 @@
<para>
To list the collations for a character set, use the <literal>SHOW
COLLATION</literal> statement. For example, to see the collations
- for the <literal>latin1</literal> (``ISO-8859-1 West European'')
- character set, use this statement to find those collation names
- that begin with <literal>latin1</literal>:
+ for the <literal>latin1</literal> (<quote>ISO-8859-1 West
+ European</quote>) character set, use this statement to find those
+ collation names that begin with <literal>latin1</literal>:
</para>
<programlisting>
@@ -633,7 +633,7 @@
<title id='title-charset-column'>&title-charset-column;</title>
<para>
- Every ``character'' column (that is, a column of type
+ Every <quote>character</quote> column (that is, a column of type
<literal>CHAR</literal>, <literal>VARCHAR</literal>, or
<literal>TEXT</literal>) has a column character set and a column
collation, which may not be null. Column definition syntax has
@@ -837,13 +837,13 @@
</para>
<para>
- Consider what a ``connection'' is: It's what you make when you
- connect to the server. The client sends SQL statements, such as
- queries, over the connection to the server. The server sends
- responses, such as result sets, over the connection back to the
- client. This leads to several questions about character set and
- collation handling for client connections, each of which can be
- answered in terms of system variables:
+ Consider what a <quote>connection</quote> is: It's what you make
+ when you connect to the server. The client sends SQL statements,
+ such as queries, over the connection to the server. The server
+ sends responses, such as result sets, over the connection back
+ to the client. This leads to several questions about character
+ set and collation handling for client connections, each of which
+ can be answered in terms of system variables:
</para>
<itemizedlist>
@@ -917,12 +917,12 @@
<para>
<literal>SET NAMES</literal> indicates what is in the SQL
statements that the client sends. Thus, <literal>SET NAMES
- 'cp1251'</literal> tells the server ``future incoming messages
- from this client are in character set
- <literal>cp1251</literal>.'' It also specifies the character set
- for results that the server sends back to the client. (For
- example, it indicates what character set column values are if
- you use a <literal>SELECT</literal> statement.)
+ 'cp1251'</literal> tells the server <quote>future incoming
+ messages from this client are in character set
+ <literal>cp1251</literal>.</quote> It also specifies the
+ character set for results that the server sends back to the
+ client. (For example, it indicates what character set column
+ values are if you use a <literal>SELECT</literal> statement.)
</para>
<para>
@@ -1058,10 +1058,10 @@
<para>
The <literal>_<replaceable>charset_name</replaceable></literal>
expression is formally called an
- <emphasis>introducer</emphasis>. It tells the parser, ``the
+ <emphasis>introducer</emphasis>. It tells the parser, <quote>the
string that is about to follow is in character set
- <literal>X</literal>.'' Because this has confused people in the
- past, we emphasize that an introducer does not cause any
+ <literal>X</literal>.</quote> Because this has confused people
+ in the past, we emphasize that an introducer does not cause any
conversion, it is strictly a signal that does not change the
string's value. An introducer is also legal before standard hex
literal and numeric hex literal notation
@@ -1313,7 +1313,8 @@
In the great majority of queries, it is obvious what collation
MySQL uses to resolve a comparison operation. For example, in
the following cases, it should be clear that the collation is
- ``the column collation of column <literal>x</literal>'':
+ <quote>the column collation of column
+ <literal>x</literal></quote>:
</para>
<programlisting>
@@ -1339,10 +1340,10 @@
<para>
Standard SQL resolves such questions using what used to be
- called ``coercibility'' rules. The essence is: Because
- <literal>x</literal> and <literal>'Y'</literal> both have
- collations, whose collation takes precedence? It's complex, but
- the following rules take care of most situations:
+ called <quote>coercibility</quote> rules. The essence is:
+ Because <literal>x</literal> and <literal>'Y'</literal> both
+ have collations, whose collation takes precedence? It's complex,
+ but the following rules take care of most situations:
</para>
<itemizedlist>
@@ -1369,8 +1370,8 @@
<listitem>
<para>
- A ``system constant'' (the string returned by functions such
- as <literal>USER()</literal> or
+ A <quote>system constant</quote> (the string returned by
+ functions such as <literal>USER()</literal> or
<literal>VERSION()</literal>) has a coercibility of 3.
</para>
</listitem>
@@ -1723,8 +1724,8 @@
<para>
For operations that combine multiple string inputs and return a
- single string output, the ``aggregation rules'' of standard SQL
- apply:
+ single string output, the <quote>aggregation rules</quote> of
+ standard SQL apply:
</para>
<itemizedlist>
@@ -1816,9 +1817,9 @@
<para>
In <literal>TRADITIONAL</literal> SQL mode, if you convert a
- ``zero'' date string to a date, <literal>CONVERT()</literal>
- returns <literal>NULL</literal>. MySQL 5.0.4 and above also
- produces a warning.
+ <quote>zero</quote> date string to a date,
+ <literal>CONVERT()</literal> returns <literal>NULL</literal>.
+ MySQL 5.0.4 and above also produces a warning.
</para>
</section>
@@ -1873,9 +1874,9 @@
<para>
In <literal>TRADITIONAL</literal> SQL mode, if you convert a
- ``zero'' date string to a date, <literal>CAST()</literal>
- returns <literal>NULL</literal>. MySQL 5.0.4 and above also
- produces a warning.
+ <quote>zero</quote> date string to a date,
+ <literal>CAST()</literal> returns <literal>NULL</literal>. MySQL
+ 5.0.4 and above also produces a warning.
</para>
</section>
@@ -2230,10 +2231,11 @@
<para>
Although automatic conversion is not in the SQL standard, the SQL
standard document does say that every character set is (in terms
- of supported characters) a ``subset'' of Unicode. Since it is a
- well-known principle that ``what applies to a superset can apply
- to a subset,'' we believe that a collation for Unicode can apply
- for comparisons with non-Unicode strings.
+ of supported characters) a <quote>subset</quote> of Unicode. Since
+ it is a well-known principle that <quote>what applies to a
+ superset can apply to a subset,</quote> we believe that a
+ collation for Unicode can apply for comparisons with non-Unicode
+ strings.
</para>
<!-- VERSION 4.1.1 NOTE: The @file{errmsg.txt} files are all in UTF8
@@ -2330,9 +2332,9 @@
</para>
<para>
- It is important to note that the ``MySQL 4.0 character set''
- contains both character set and collation information in one
- single entity. Beginning in MySQL 4.1, character sets and
+ It is important to note that the <quote>MySQL 4.0 character
+ set</quote> contains both character set and collation information
+ in one single entity. Beginning in MySQL 4.1, character sets and
collations are separate entities. Though each collation
corresponds to a particular character set, the two are not bundled
together.
@@ -2660,7 +2662,7 @@
</programlisting>
<para>
- The first two statements ``remove'' the character set
+ The first two statements <quote>remove</quote> the character set
information from the <literal>latin2_col</literal> and
<literal>utf8_col</literal> columns. The second two statements
assign the proper character sets to the two columns.
@@ -3128,7 +3130,7 @@
If that is acceptable for your application, use
<literal>utf8_general_ci</literal> because it is faster.
Otherwise, use <literal>utf8_unicode_ci</literal> because it is
- ``smarter.''
+ <quote>smarter.</quote>
</para>
<para>
--- 1.9/refman-5.0/charset.xml 2005-07-19 10:57:27 -05:00
+++ 1.10/refman-5.0/charset.xml 2005-07-26 21:27:49 -05:00
@@ -124,8 +124,8 @@
is less than 1, we say '<literal>A</literal>' is less than
'<literal>B</literal>'. What we've just done is apply a collation
to our character set. The collation is a set of rules (only one
- rule in this case): ``compare the encodings.'' We call this
- simplest of all possible collations a
+ rule in this case): <quote>compare the encodings.</quote> We call
+ this simplest of all possible collations a
<emphasis role="bold">binary</emphasis> collation.
</para>
@@ -146,10 +146,10 @@
with thousands of characters, along with many special symbols and
punctuation marks. Also in real life, most collations have many
rules: not just case insensitivity but also accent insensitivity
- (an ``accent'' is a mark attached to a character as in German
- '<literal>Ö</literal>') and multiple-character mappings (such as
- the rule that '<literal>Ö</literal>' = '<literal>OE</literal>' in
- one of the two German collations).
+ (an <quote>accent</quote> is a mark attached to a character as in
+ German '<literal>Ö</literal>') and multiple-character mappings
+ (such as the rule that '<literal>Ö</literal>' =
+ '<literal>OE</literal>' in one of the two German collations).
</para>
<para>
@@ -247,9 +247,9 @@
<para>
To list the collations for a character set, use the <literal>SHOW
COLLATION</literal> statement. For example, to see the collations
- for the <literal>latin1</literal> (``ISO-8859-1 West European'')
- character set, use this statement to find those collation names
- that begin with <literal>latin1</literal>:
+ for the <literal>latin1</literal> (<quote>ISO-8859-1 West
+ European</quote>) character set, use this statement to find those
+ collation names that begin with <literal>latin1</literal>:
</para>
<!-- NOTE: Please do not cut this list. -->
@@ -632,7 +632,7 @@
<title id='title-charset-column'>&title-charset-column;</title>
<para>
- Every ``character'' column (that is, a column of type
+ Every <quote>character</quote> column (that is, a column of type
<literal>CHAR</literal>, <literal>VARCHAR</literal>, or
<literal>TEXT</literal>) has a column character set and a column
collation, which may not be null. Column definition syntax has
@@ -839,13 +839,13 @@
</para>
<para>
- Consider what a ``connection'' is: It's what you make when you
- connect to the server. The client sends SQL statements, such as
- queries, over the connection to the server. The server sends
- responses, such as result sets, over the connection back to the
- client. This leads to several questions about character set and
- collation handling for client connections, each of which can be
- answered in terms of system variables:
+ Consider what a <quote>connection</quote> is: It's what you make
+ when you connect to the server. The client sends SQL statements,
+ such as queries, over the connection to the server. The server
+ sends responses, such as result sets, over the connection back
+ to the client. This leads to several questions about character
+ set and collation handling for client connections, each of which
+ can be answered in terms of system variables:
</para>
<itemizedlist>
@@ -919,12 +919,12 @@
<para>
<literal>SET NAMES</literal> indicates what is in the SQL
statements that the client sends. Thus, <literal>SET NAMES
- 'cp1251'</literal> tells the server ``future incoming messages
- from this client are in character set
- <literal>cp1251</literal>.'' It also specifies the character set
- for results that the server sends back to the client. (For
- example, it indicates what character set column values are if
- you use a <literal>SELECT</literal> statement.)
+ 'cp1251'</literal> tells the server <quote>future incoming
+ messages from this client are in character set
+ <literal>cp1251</literal>.</quote> It also specifies the
+ character set for results that the server sends back to the
+ client. (For example, it indicates what character set column
+ values are if you use a <literal>SELECT</literal> statement.)
</para>
<para>
@@ -1060,13 +1060,13 @@
<para>
The <literal>_<replaceable>charset_name</replaceable></literal>
expression is formally called an
- <emphasis>introducer</emphasis>. It tells the parser, ``the
+ <emphasis>introducer</emphasis>. It tells the parser, <quote>the
string that is about to follow uses character set
- <replaceable>X</replaceable>.'' Because this has confused people
- in the past, we emphasize that an introducer does not cause any
- conversion; it is strictly a signal that does not change the
- string's value. An introducer is also legal before standard hex
- literal and numeric hex literal notation
+ <replaceable>X</replaceable>.</quote> Because this has confused
+ people in the past, we emphasize that an introducer does not
+ cause any conversion; it is strictly a signal that does not
+ change the string's value. An introducer is also legal before
+ standard hex literal and numeric hex literal notation
(<literal>x'<replaceable>literal</replaceable>'</literal> and
<literal>0x<replaceable>nnnn</replaceable></literal>), and
before <literal>?</literal> (parameter substitution when using
@@ -1325,7 +1325,8 @@
In the great majority of queries, it is obvious what collation
MySQL uses to resolve a comparison operation. For example, in
the following cases, it should be clear that the collation is
- ``the column collation of column <literal>x</literal>'':
+ <quote>the column collation of column
+ <literal>x</literal></quote>:
</para>
<programlisting>
@@ -1351,10 +1352,11 @@
<para>
Standard SQL resolves such questions using what used to be
- called ``coercibility'' rules. Basically, this means: Since both
- <literal>x</literal> and <literal>'Y'</literal> have collations,
- whose collation takes precedence? This can be difficult to
- resolve, but the following rules take care of most situations:
+ called <quote>coercibility</quote> rules. Basically, this means:
+ Since both <literal>x</literal> and <literal>'Y'</literal> have
+ collations, whose collation takes precedence? This can be
+ difficult to resolve, but the following rules take care of most
+ situations:
</para>
<itemizedlist>
@@ -1381,8 +1383,8 @@
<listitem>
<para>
- A ``system constant'' (the string returned by functions such
- as <literal>USER()</literal> or
+ A <quote>system constant</quote> (the string returned by
+ functions such as <literal>USER()</literal> or
<literal>VERSION()</literal>) has a coercibility of 3.
</para>
</listitem>
@@ -1649,8 +1651,8 @@
<para>
For operations that combine multiple string inputs and return a
- single string output, the ``aggregation rules'' of standard SQL
- apply:
+ single string output, the <quote>aggregation rules</quote> of
+ standard SQL apply:
</para>
<itemizedlist>
@@ -1745,9 +1747,9 @@
<para>
In <literal>TRADITIONAL</literal> SQL mode, if you convert a
- ``zero'' date string to a date, <literal>CONVERT()</literal>
- returns <literal>NULL</literal>. MySQL 5.0.4 and above also
- produce a warning.
+ <quote>zero</quote> date string to a date,
+ <literal>CONVERT()</literal> returns <literal>NULL</literal>.
+ MySQL 5.0.4 and above also produce a warning.
</para>
</section>
@@ -1802,9 +1804,9 @@
<para>
In <literal>TRADITIONAL</literal> SQL mode, if you convert a
- ``zero'' date string to a date, <literal>CAST()</literal>
- returns <literal>NULL</literal>. MySQL 5.0.4 and above also
- produce a warning.
+ <quote>zero</quote> date string to a date,
+ <literal>CAST()</literal> returns <literal>NULL</literal>. MySQL
+ 5.0.4 and above also produce a warning.
</para>
</section>
@@ -2175,10 +2177,11 @@
<para>
Although automatic conversion is not in the SQL standard, the SQL
standard document does say that every character set is (in terms
- of supported characters) a ``subset'' of Unicode. Since it is a
- well-known principle that ``what applies to a superset can apply
- to a subset,'' we believe that a collation for Unicode can apply
- for comparisons with non-Unicode strings.
+ of supported characters) a <quote>subset</quote> of Unicode. Since
+ it is a well-known principle that <quote>what applies to a
+ superset can apply to a subset,</quote> we believe that a
+ collation for Unicode can apply for comparisons with non-Unicode
+ strings.
</para>
<!--
--- 1.8/refman/charset.xml 2005-07-19 10:57:37 -05:00
+++ 1.9/refman/charset.xml 2005-07-26 21:27:49 -05:00
@@ -136,8 +136,8 @@
is less than 1, we say '<literal>A</literal>' is less than
'<literal>B</literal>'. What we've just done is apply a collation
to our character set. The collation is a set of rules (only one
- rule in this case): ``compare the encodings.'' We call this
- simplest of all possible collations a
+ rule in this case): <quote>compare the encodings.</quote> We call
+ this simplest of all possible collations a
<emphasis role="bold">binary</emphasis> collation.
</para>
@@ -158,10 +158,10 @@
with thousands of characters, along with many special symbols and
punctuation marks. Also in real life, most collations have many
rules: not just case insensitivity but also accent insensitivity
- (an ``accent'' is a mark attached to a character as in German
- '<literal>Ö</literal>') and multiple-character mappings (such as
- the rule that '<literal>Ö</literal>' = '<literal>OE</literal>' in
- one of the two German collations).
+ (an <quote>accent</quote> is a mark attached to a character as in
+ German '<literal>Ö</literal>') and multiple-character mappings
+ (such as the rule that '<literal>Ö</literal>' =
+ '<literal>OE</literal>' in one of the two German collations).
</para>
<para>
@@ -251,9 +251,9 @@
<para>
To list the collations for a character set, use the <literal>SHOW
COLLATION</literal> statement. For example, to see the collations
- for the <literal>latin1</literal> (``ISO-8859-1 West European'')
- character set, use this statement to find those collation names
- that begin with <literal>latin1</literal>:
+ for the <literal>latin1</literal> (<quote>ISO-8859-1 West
+ European</quote>) character set, use this statement to find those
+ collation names that begin with <literal>latin1</literal>:
</para>
<programlisting>
@@ -633,7 +633,7 @@
<title id='title-charset-column'>&title-charset-column;</title>
<para>
- Every ``character'' column (that is, a column of type
+ Every <quote>character</quote> column (that is, a column of type
<literal>CHAR</literal>, <literal>VARCHAR</literal>, or
<literal>TEXT</literal>) has a column character set and a column
collation, which may not be null. Column definition syntax has
@@ -837,13 +837,13 @@
</para>
<para>
- Consider what a ``connection'' is: It's what you make when you
- connect to the server. The client sends SQL statements, such as
- queries, over the connection to the server. The server sends
- responses, such as result sets, over the connection back to the
- client. This leads to several questions about character set and
- collation handling for client connections, each of which can be
- answered in terms of system variables:
+ Consider what a <quote>connection</quote> is: It's what you make
+ when you connect to the server. The client sends SQL statements,
+ such as queries, over the connection to the server. The server
+ sends responses, such as result sets, over the connection back
+ to the client. This leads to several questions about character
+ set and collation handling for client connections, each of which
+ can be answered in terms of system variables:
</para>
<itemizedlist>
@@ -917,12 +917,12 @@
<para>
<literal>SET NAMES</literal> indicates what is in the SQL
statements that the client sends. Thus, <literal>SET NAMES
- 'cp1251'</literal> tells the server ``future incoming messages
- from this client are in character set
- <literal>cp1251</literal>.'' It also specifies the character set
- for results that the server sends back to the client. (For
- example, it indicates what character set column values are if
- you use a <literal>SELECT</literal> statement.)
+ 'cp1251'</literal> tells the server <quote>future incoming
+ messages from this client are in character set
+ <literal>cp1251</literal>.</quote> It also specifies the
+ character set for results that the server sends back to the
+ client. (For example, it indicates what character set column
+ values are if you use a <literal>SELECT</literal> statement.)
</para>
<para>
@@ -1058,10 +1058,10 @@
<para>
The <literal>_<replaceable>charset_name</replaceable></literal>
expression is formally called an
- <emphasis>introducer</emphasis>. It tells the parser, ``the
+ <emphasis>introducer</emphasis>. It tells the parser, <quote>the
string that is about to follow is in character set
- <literal>X</literal>.'' Because this has confused people in the
- past, we emphasize that an introducer does not cause any
+ <literal>X</literal>.</quote> Because this has confused people
+ in the past, we emphasize that an introducer does not cause any
conversion, it is strictly a signal that does not change the
string's value. An introducer is also legal before standard hex
literal and numeric hex literal notation
@@ -1313,7 +1313,8 @@
In the great majority of queries, it is obvious what collation
MySQL uses to resolve a comparison operation. For example, in
the following cases, it should be clear that the collation is
- ``the column collation of column <literal>x</literal>'':
+ <quote>the column collation of column
+ <literal>x</literal></quote>:
</para>
<programlisting>
@@ -1339,10 +1340,10 @@
<para>
Standard SQL resolves such questions using what used to be
- called ``coercibility'' rules. The essence is: Because
- <literal>x</literal> and <literal>'Y'</literal> both have
- collations, whose collation takes precedence? It's complex, but
- the following rules take care of most situations:
+ called <quote>coercibility</quote> rules. The essence is:
+ Because <literal>x</literal> and <literal>'Y'</literal> both
+ have collations, whose collation takes precedence? It's complex,
+ but the following rules take care of most situations:
</para>
<itemizedlist>
@@ -1369,8 +1370,8 @@
<listitem>
<para>
- A ``system constant'' (the string returned by functions such
- as <literal>USER()</literal> or
+ A <quote>system constant</quote> (the string returned by
+ functions such as <literal>USER()</literal> or
<literal>VERSION()</literal>) has a coercibility of 3.
</para>
</listitem>
@@ -1723,8 +1724,8 @@
<para>
For operations that combine multiple string inputs and return a
- single string output, the ``aggregation rules'' of standard SQL
- apply:
+ single string output, the <quote>aggregation rules</quote> of
+ standard SQL apply:
</para>
<itemizedlist>
@@ -1816,9 +1817,9 @@
<para>
In <literal>TRADITIONAL</literal> SQL mode, if you convert a
- ``zero'' date string to a date, <literal>CONVERT()</literal>
- returns <literal>NULL</literal>. MySQL 5.0.4 and above also
- produces a warning.
+ <quote>zero</quote> date string to a date,
+ <literal>CONVERT()</literal> returns <literal>NULL</literal>.
+ MySQL 5.0.4 and above also produces a warning.
</para>
</section>
@@ -1873,9 +1874,9 @@
<para>
In <literal>TRADITIONAL</literal> SQL mode, if you convert a
- ``zero'' date string to a date, <literal>CAST()</literal>
- returns <literal>NULL</literal>. MySQL 5.0.4 and above also
- produces a warning.
+ <quote>zero</quote> date string to a date,
+ <literal>CAST()</literal> returns <literal>NULL</literal>. MySQL
+ 5.0.4 and above also produces a warning.
</para>
</section>
@@ -2230,10 +2231,11 @@
<para>
Although automatic conversion is not in the SQL standard, the SQL
standard document does say that every character set is (in terms
- of supported characters) a ``subset'' of Unicode. Since it is a
- well-known principle that ``what applies to a superset can apply
- to a subset,'' we believe that a collation for Unicode can apply
- for comparisons with non-Unicode strings.
+ of supported characters) a <quote>subset</quote> of Unicode. Since
+ it is a well-known principle that <quote>what applies to a
+ superset can apply to a subset,</quote> we believe that a
+ collation for Unicode can apply for comparisons with non-Unicode
+ strings.
</para>
<!-- VERSION 4.1.1 NOTE: The @file{errmsg.txt} files are all in UTF8
@@ -2330,9 +2332,9 @@
</para>
<para>
- It is important to note that the ``MySQL 4.0 character set''
- contains both character set and collation information in one
- single entity. Beginning in MySQL 4.1, character sets and
+ It is important to note that the <quote>MySQL 4.0 character
+ set</quote> contains both character set and collation information
+ in one single entity. Beginning in MySQL 4.1, character sets and
collations are separate entities. Though each collation
corresponds to a particular character set, the two are not bundled
together.
@@ -2660,7 +2662,7 @@
</programlisting>
<para>
- The first two statements ``remove'' the character set
+ The first two statements <quote>remove</quote> the character set
information from the <literal>latin2_col</literal> and
<literal>utf8_col</literal> columns. The second two statements
assign the proper character sets to the two columns.
@@ -3128,7 +3130,7 @@
If that is acceptable for your application, use
<literal>utf8_general_ci</literal> because it is faster.
Otherwise, use <literal>utf8_unicode_ci</literal> because it is
- ``smarter.''
+ <quote>smarter.</quote>
</para>
<para>
| Thread |
|---|
| • bk commit - mysqldoc@docsrva tree (paul:1.3138) | paul | 27 Jul |
