Author: paul
Date: 2006-01-18 20:32:04 +0100 (Wed, 18 Jan 2006)
New Revision: 905
Log:
r2298@kite-hub: paul | 2006-01-18 13:30:09 -0600
General revisions.
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:6354
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2297
+ b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6354
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2298
Modified: trunk/refman-4.1/data-types.xml
===================================================================
--- trunk/refman-4.1/data-types.xml 2006-01-18 19:31:50 UTC (rev 904)
+++ trunk/refman-4.1/data-types.xml 2006-01-18 19:32:04 UTC (rev 905)
@@ -854,7 +854,7 @@
<para>
These types are synonyms for <literal>DECIMAL</literal>. The
<literal>FIXED</literal> synonym was added in MySQL 4.1.0
- for compatibility with other servers.
+ for compatibility with other database systems.
</para>
<remark role="help-description-end"/>
@@ -988,13 +988,15 @@
<para>
A <literal>TIMESTAMP</literal> column is useful for
recording the date and time of an <literal>INSERT</literal>
- or <literal>UPDATE</literal> operation. The first
- <literal>TIMESTAMP</literal> column in a table is
+ or <literal>UPDATE</literal> operation. By default, the
+ first <literal>TIMESTAMP</literal> column in a table is
automatically set to the date and time of the most recent
operation if you do not assign it a value yourself. You can
also set any <literal>TIMESTAMP</literal> column to the
current date and time by assigning it a
- <literal>NULL</literal> value.
+ <literal>NULL</literal> value. Variations on automatic
+ initialization and update properties are described in
+ <xref linkend="timestamp-4-1"/>.
</para>
<para>
@@ -1140,7 +1142,9 @@
</para>
<para>
- As of MySQL 4.1, several changes affect string data types:
+ In MySQL 4.1 and up, string data types include some features
+ that you may not have encountered in working with previous
+ versions of MySQL (prior to 4.1):
</para>
<itemizedlist>
@@ -1149,9 +1153,10 @@
<para>
Column definitions for many string data types can include a
<literal>CHARACTER SET</literal> attribute to specify the
- character set and, optionally, a collation.
- (<literal>CHARSET</literal> is a synonym for
- <literal>CHARACTER SET</literal>.) These attributes apply to
+ character set. (<literal>CHARSET</literal> is a synonym for
+ <literal>CHARACTER SET</literal>.) The
+ <literal>COLLATE</literal> attribute specifies a collation
+ for the the character set. These attributes apply to
<literal>CHAR</literal>, <literal>VARCHAR</literal>, the
<literal>TEXT</literal> types, <literal>ENUM</literal>, and
<literal>SET</literal>. For example:
@@ -1160,8 +1165,8 @@
<programlisting>
CREATE TABLE t
(
- c1 CHAR(20) CHARACTER SET utf8,
- c2 CHAR(20) CHARACTER SET latin1 COLLATE latin1_bin
+ c1 VARCHAR(20) CHARACTER SET utf8,
+ c2 TEXT CHARACTER SET latin1 COLLATE latin1_general_cs
);
</programlisting>
@@ -1170,18 +1175,17 @@
<literal>c1</literal> that has a character set of
<literal>utf8</literal> with the default collation for that
character set, and a column named <literal>c2</literal> that
- has a character set of <literal>latin1</literal> and the
- binary collation for the character set. The binary collation
- is not case sensitive.
+ has a character set of <literal>latin1</literal> and a
+ case-sensitive collation.
</para>
</listitem>
<listitem>
<para>
- <emphasis role="bold">Note</emphasis>: In MySQL 4.1, MySQL
- interprets length specifications in character column
- definitions in character units. Earlier versions interpret
- lengths in byte units.
+ <emphasis role="bold">Note</emphasis>: As of MySQL 4.1,
+ MySQL interprets length specifications in character column
+ definitions in character units. (Previously, MySQL
+ interpreted lengths in bytes.)
</para>
</listitem>
@@ -1191,31 +1195,32 @@
the <literal>TEXT</literal> types, the
<literal>BINARY</literal> attribute causes the column to be
assigned the binary collation of the column character set.
- For earlier versions, <literal>BINARY</literal> causes
+ (Previously, <literal>BINARY</literal> caused
<literal>CHAR</literal> and <literal>VARCHAR</literal> to be
- treated as binary strings and is disallowed for the
- <literal>TEXT</literal> types.
+ treated as binary strings and was disallowed for the
+ <literal>TEXT</literal> types.)
</para>
</listitem>
<listitem>
<para>
Character column sorting and comparison are based on the
- character set assigned to the column. For earlier versions,
- sorting and comparison are based on the collation of the
- server character set. For <literal>CHAR</literal> and
+ character set assigned to the column. (Previously sorting
+ and comparison were based on the collation of the server
+ character set.) For <literal>CHAR</literal> and
<literal>VARCHAR</literal> columns, you can declare the
- column with the <literal>BINARY</literal> attribute to cause
- sorting and comparison to use the underlying character code
- values rather then a lexical ordering.
+ column with a binary collation or the
+ <literal>BINARY</literal> attribute to cause sorting and
+ comparison to use the underlying character code values
+ rather then a lexical ordering.
</para>
</listitem>
</itemizedlist>
<para>
- For more details about character set support in MySQL 4.1 and
- up, see <xref linkend="charset"/>.
+ <xref linkend="charset"/>, provides additional information about
+ use of character sets in MySQL 4.1 and up.
</para>
<itemizedlist>
@@ -1786,7 +1791,7 @@
<secondary>ENUM</secondary>
</indexterm>
- <literal>ENUM('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',...)</literal>
+ <literal>ENUM('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',…)</literal>
</para>
<para>
@@ -1794,7 +1799,7 @@
value, chosen from the list of values
<literal>'<replaceable>value1</replaceable>'</literal>,
<literal>'<replaceable>value2</replaceable>'</literal>,
- <literal>...</literal>, <literal>NULL</literal> or the
+ <literal>…</literal>, <literal>NULL</literal> or the
special <literal>''</literal> error value. An
<literal>ENUM</literal> column can have a maximum of 65,535
distinct values. <literal>ENUM</literal> values are
@@ -1819,7 +1824,7 @@
<secondary>SET</secondary>
</indexterm>
- <literal>SET('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',...)</literal>
+ <literal>SET('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',…)</literal>
</para>
<para>
@@ -1827,9 +1832,9 @@
each of which must be chosen from the list of values
<literal>'<replaceable>value1</replaceable>'</literal>,
<literal>'<replaceable>value2</replaceable>'</literal>,
- <literal>...</literal> A <literal>SET</literal> column can
- have a maximum of 64 members. <literal>SET</literal> values
- are represented internally as integers.
+ <literal>…</literal> A <literal>SET</literal> column
+ can have a maximum of 64 members. <literal>SET</literal>
+ values are represented internally as integers.
</para>
<remark role="help-description-end"/>
@@ -1982,7 +1987,7 @@
All integer types can have an optional (non-standard) attribute
<literal>UNSIGNED</literal>. Unsigned values can be used when you
want to allow only non-negative numbers in a column and you need a
- bigger upper numeric range for the column.
+ larger upper numeric range for the column.
</para>
<para>
@@ -2265,8 +2270,8 @@
you specify a value to be assigned to or compared to a date or
time type). Only the formats described in the following
sections are supported. It is expected that you supply legal
- values, and unpredictable results may occur if you use values
- in other formats.
+ values. Unpredictable results may occur if you use values in
+ other formats.
</para>
</listitem>
@@ -2344,7 +2349,11 @@
<entry><literal>'0000-00-00'</literal></entry>
</row>
<row>
- <entry><literal>TIMESTAMP</literal></entry>
+ <entry><literal>TIMESTAMP</literal> (4.1 and up)</entry>
+ <entry><literal>'0000-00-00 00:00:00'</literal></entry>
+ </row>
+ <row>
+ <entry><literal>TIMESTAMP</literal> (before 4.1)</entry>
<entry><literal>00000000000000</literal></entry>
</row>
<row>
@@ -3391,7 +3400,7 @@
<para>
Otherwise — that is, if the <literal>TIMESTAMP</literal>
column is defined using <literal>NULL</literal> but not using
- <literal>DEFAULT TIMESTAMP</literal>, as shown here:
+ <literal>DEFAULT TIMESTAMP</literal>, as shown here…
</para>
<programlisting>
@@ -3400,7 +3409,7 @@
</programlisting>
<para>
- — then you must explicitly insert a value corresponding
+ …then you must explicitly insert a value corresponding
to the current date and time, for example:
</para>
@@ -3458,7 +3467,7 @@
HH:MM'</literal>, <literal>'D HH'</literal>, or
<literal>'SS'</literal>. Here <literal>D</literal>
represents days and can have a value from 0 to 34. Note that
- MySQL does not yet store the fraction part.
+ MySQL does not store the fraction part.
</para>
</listitem>
@@ -4069,14 +4078,42 @@
<para>
You should consider the preceding padding and stripping
- characteristics carefully if you plan to use these data types
- for storing binary data and you require that the value retrieved
- be exactly the same as the value stored. It might be preferable
- to use one of the <literal>BLOB</literal> data types instead.
+ characteristics carefully if you plan to use one of these data
+ types for storing binary data and you require that the value
+ retrieved be exactly the same as the value stored. The following
+ example illustrates how <literal>0x00</literal>-padding of
+ <literal>BINARY</literal> values affects column value
+ comparisons:
</para>
+<programlisting>
+<!--
+mysql> DROP TABLE IF EXISTS t;
+Query OK, 0 rows affected (0.00 sec)
+-->
+mysql> <userinput>CREATE TABLE t (c BINARY(3));</userinput>
+Query OK, 0 rows affected (0.01 sec)
+
+mysql> <userinput>INSERT INTO t SET c = 'a';</userinput>
+Query OK, 1 row affected (0.01 sec)
+
+mysql> <userinput>SELECT HEX(c), c = 'a', c = 'a\0\0' from t;</userinput>
++--------+---------+-------------+
+| HEX(c) | c = 'a' | c = 'a\0\0' |
++--------+---------+-------------+
+| 610000 | 0 | 1 |
++--------+---------+-------------+
+1 row in set (0.09 sec)
+</programlisting>
+
<para>
- MySQL may silently change the type of a
+ If the value retrieved must be the same as the value specified
+ for storage with no padding, it might be preferable to use one
+ 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"/>.
@@ -4222,7 +4259,8 @@
For indexes on <literal>BLOB</literal> and
<literal>TEXT</literal> columns, you must specify an index
prefix length. For <literal>CHAR</literal> and
- <literal>VARCHAR</literal>, a prefix length is optional.
+ <literal>VARCHAR</literal>, a prefix length is optional. See
+ <xref linkend="indexes"/>.
</para>
</listitem>
@@ -4432,18 +4470,16 @@
<listitem>
<para>
Values from the list of allowable elements in the column
- specification are numbered beginning with
- <literal>1</literal>.
+ specification are numbered beginning with 1.
</para>
</listitem>
<listitem>
<para>
- The index value of the empty string error value is
- <literal>0</literal>. This means that you can use the
- following <literal>SELECT</literal> statement to find rows
- into which invalid <literal>ENUM</literal> values were
- assigned:
+ The index value of the empty string error value is 0. This
+ means that you can use the following
+ <literal>SELECT</literal> statement to find rows into which
+ invalid <literal>ENUM</literal> values were assigned:
</para>
<programlisting>
@@ -5101,12 +5137,12 @@
< 2<superscript>32</superscript></entry>
</row>
<row>
- <entry><literal>ENUM('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',...)</literal></entry>
+ <entry><literal>ENUM('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',…)</literal></entry>
<entry>1 or 2 bytes, depending on the number of enumeration values (65,535
values maximum)</entry>
</row>
<row>
- <entry><literal>SET('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',...)</literal></entry>
+ <entry><literal>SET('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',…)</literal></entry>
<entry>1, 2, 3, 4, or 8 bytes, depending on the number of set members (64
members maximum)</entry>
</row>
Modified: trunk/refman-5.0/data-types.xml
===================================================================
--- trunk/refman-5.0/data-types.xml 2006-01-18 19:31:50 UTC (rev 904)
+++ trunk/refman-5.0/data-types.xml 2006-01-18 19:32:04 UTC (rev 905)
@@ -463,7 +463,7 @@
All arithmetic is done using signed
<literal>BIGINT</literal> or <literal>DOUBLE</literal>
- values, so you shouldn't use unsigned big integers
+ values, so you should not use unsigned big integers
larger than <literal>9223372036854775807</literal> (63
bits) except with bit functions! If you do that, some of
the last digits in the result may be wrong because of
@@ -481,8 +481,8 @@
<listitem>
<para>
- When using integers to store big unsigned values in
- a <literal>BIGINT</literal> column.
+ When using integers to store large unsigned values
+ in a <literal>BIGINT</literal> column.
</para>
</listitem>
@@ -835,8 +835,8 @@
</para>
<para>
- If <literal>UNSIGNED</literal> is specified, negative values
- are disallowed.
+ <literal>UNSIGNED</literal>, if specified, disallows
+ negative values.
</para>
<remark role="help-description-end"/>
@@ -1024,13 +1024,15 @@
<para>
A <literal>TIMESTAMP</literal> column is useful for
recording the date and time of an <literal>INSERT</literal>
- or <literal>UPDATE</literal> operation. The first
- <literal>TIMESTAMP</literal> column in a table is
+ or <literal>UPDATE</literal> operation. By default, the
+ first <literal>TIMESTAMP</literal> column in a table is
automatically set to the date and time of the most recent
- operation if you don't assign it a value yourself. You can
+ operation if you do not assign it a value yourself. You can
also set any <literal>TIMESTAMP</literal> column to the
current date and time by assigning it a
- <literal>NULL</literal> value.
+ <literal>NULL</literal> value. Variations on automatic
+ initialization and update properties are described in
+ <xref linkend="timestamp-4-1"/>.
</para>
<para>
@@ -1144,9 +1146,9 @@
</para>
<para>
- MySQL ¤t-series; string data types include some features
- that you may not have encountered in working with versions of
- MySQL prior to 4.1:
+ In MySQL 4.1 and up, string data types include some features
+ that you may not have encountered in working with previous
+ versions of MySQL (prior to 4.1):
</para>
<itemizedlist>
@@ -1155,9 +1157,10 @@
<para>
Column definitions for many string data types can include a
<literal>CHARACTER SET</literal> attribute to specify the
- character set and, optionally, a collation.
- (<literal>CHARSET</literal> is a synonym for
- <literal>CHARACTER SET</literal>.) These attributes apply to
+ character set. (<literal>CHARSET</literal> is a synonym for
+ <literal>CHARACTER SET</literal>.) The
+ <literal>COLLATE</literal> attribute specifies a collation
+ for the the character set. These attributes apply to
<literal>CHAR</literal>, <literal>VARCHAR</literal>, the
<literal>TEXT</literal> types, <literal>ENUM</literal>, and
<literal>SET</literal>. For example:
@@ -1166,8 +1169,8 @@
<programlisting>
CREATE TABLE t
(
- c1 CHAR(20) CHARACTER SET utf8,
- c2 CHAR(20) CHARACTER SET latin1 COLLATE latin1_bin
+ c1 VARCHAR(20) CHARACTER SET utf8,
+ c2 TEXT CHARACTER SET latin1 COLLATE latin1_general_cs
);
</programlisting>
@@ -1176,17 +1179,16 @@
<literal>c1</literal> that has a character set of
<literal>utf8</literal> with the default collation for that
character set, and a column named <literal>c2</literal> that
- has a character set of <literal>latin1</literal> and the
- binary collation for the character set. The binary collation
- is not case sensitive.
+ has a character set of <literal>latin1</literal> and a
+ case-sensitive collation.
</para>
</listitem>
<listitem>
<para>
MySQL ¤t-series; interprets length specifications in
- character column definitions in character units. (Some
- earlier MySQL versions interpreted lengths in bytes.)
+ character column definitions in character units.
+ (Previously, MySQL interpreted lengths in bytes.)
</para>
</listitem>
@@ -1196,27 +1198,30 @@
the <literal>TEXT</literal> types, the
<literal>BINARY</literal> attribute causes the column to be
assigned the binary collation of the column character set.
+ (Previously, <literal>BINARY</literal> caused a column to
+ store binary strings.)
</para>
</listitem>
<listitem>
<para>
Character column sorting and comparison are based on the
- character set assigned to the column. For earlier versions,
- sorting and comparison are based on the collation of the
- server character set. For <literal>CHAR</literal> and
+ character set assigned to the column. (Previously, sorting
+ and comparison were based on the collation of the server
+ character set.) For <literal>CHAR</literal> and
<literal>VARCHAR</literal> columns, you can declare the
- column with the <literal>BINARY</literal> attribute to cause
- sorting and comparison to use the underlying character code
- values rather then a lexical ordering.
+ column with a binary collation or the
+ <literal>BINARY</literal> attribute to cause sorting and
+ comparison to use the underlying character code values
+ rather than a lexical ordering.
</para>
</listitem>
</itemizedlist>
<para>
- For more about character set support in MySQL ¤t-series;,
- see <xref linkend="charset"/>.
+ <xref linkend="charset"/>, provides additional information about
+ use of character sets in MySQL.
</para>
<itemizedlist>
@@ -1307,7 +1312,8 @@
<programlisting>
mysql> <userinput>CREATE TABLE c1 (col1 INT, col2 CHAR(500));</userinput>
-ERROR 1074 (42000): Column length too big for column 'col' (max = 255); use BLOB or TEXT instead
+ERROR 1074 (42000): Column length too big for column 'col' (max = 255);
+use BLOB or TEXT instead
mysql> <userinput>SHOW CREATE TABLE c1;</userinput>
ERROR 1146 (42S02): Table 'test.c1' doesn't exist
</programlisting>
@@ -1793,7 +1799,7 @@
<secondary>ENUM</secondary>
</indexterm>
- <literal>ENUM('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',...)</literal>
+ <literal>ENUM('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',…)</literal>
</para>
<para>
@@ -1801,7 +1807,7 @@
value, chosen from the list of values
<literal>'<replaceable>value1</replaceable>'</literal>,
<literal>'<replaceable>value2</replaceable>'</literal>,
- <literal>...</literal>, <literal>NULL</literal> or the
+ <literal>…</literal>, <literal>NULL</literal> or the
special <literal>''</literal> error value. An
<literal>ENUM</literal> column can have a maximum of 65,535
distinct values. <literal>ENUM</literal> values are
@@ -1826,7 +1832,7 @@
<secondary>SET</secondary>
</indexterm>
- <literal>SET('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',...)</literal>
+ <literal>SET('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',…)</literal>
</para>
<para>
@@ -1834,9 +1840,9 @@
each of which must be chosen from the list of values
<literal>'<replaceable>value1</replaceable>'</literal>,
<literal>'<replaceable>value2</replaceable>'</literal>,
- <literal>...</literal> A <literal>SET</literal> column can
- have a maximum of 64 members. <literal>SET</literal> values
- are represented internally as integers.
+ <literal>…</literal> A <literal>SET</literal> column
+ can have a maximum of 64 members. <literal>SET</literal>
+ values are represented internally as integers.
</para>
<remark role="help-description-end"/>
@@ -1999,7 +2005,7 @@
All integer types can have an optional (non-standard) attribute
<literal>UNSIGNED</literal>. Unsigned values can be used when you
want to allow only non-negative numbers in a column and you need a
- bigger upper numeric range for the column.
+ larger upper numeric range for the column.
</para>
<para>
@@ -2183,8 +2189,7 @@
<literal>traditional</literal> (<quote>strict mode</quote>), a
value that is out of range is rejected with an error, and the
insert fails, in accordance with the SQL standard. See
- <xref
- linkend="server-sql-mode"/>.
+ <xref linkend="server-sql-mode"/>.
</para>
<remark role="todo">
@@ -2280,7 +2285,7 @@
because MySQL allows you to store dates where the day or month and
day are zero in a <literal>DATE</literal> or
<literal>DATETIME</literal> column. This is extremely useful for
- applications that need to store a birthdate for which you don't
+ applications that need to store a birthdate for which you do not
know the exact date. In this case, you simply store the date as
<literal>'1999-00-00'</literal> or
<literal>'1999-01-00'</literal>. If you store dates such as these,
@@ -2407,7 +2412,7 @@
</row>
<row>
<entry><literal>TIMESTAMP</literal></entry>
- <entry><literal>00000000000000</literal></entry>
+ <entry><literal>'0000-00-00 00:00:00'</literal></entry>
</row>
<row>
<entry><literal>TIME</literal></entry>
@@ -3092,10 +3097,6 @@
);
</programlisting>
- <remark>
- Updated following to fix Bug#10104
- </remark>
-
<para>
If the <literal>NULL</literal> attribute is not specified,
setting the column to <literal>NULL</literal> sets it to the
@@ -3117,9 +3118,9 @@
</programlisting>
<para>
- Otherwise - that is, if the <literal>TIMESTAMP</literal>
+ Otherwise — that is, if the <literal>TIMESTAMP</literal>
column is defined using <literal>NULL</literal> but not using
- <literal>DEFAULT TIMESTAMP</literal>, as shown here...
+ <literal>DEFAULT TIMESTAMP</literal>, as shown here…
</para>
<programlisting>
@@ -3128,8 +3129,8 @@
</programlisting>
<para>
- ...then you must explicitly insert a value corresponding to
- the current date and time. For example:
+ …then you must explicitly insert a value corresponding
+ to the current date and time. For example:
</para>
<programlisting>
@@ -3186,7 +3187,7 @@
HH:MM'</literal>, <literal>'D HH'</literal>, or
<literal>'SS'</literal>. Here <literal>D</literal>
represents days and can have a value from 0 to 34. Note that
- MySQL does not (yet) store the fraction.
+ MySQL does not store the fraction part.
</para>
</listitem>
@@ -3209,8 +3210,8 @@
<literal>'10:11:12'</literal>. The following alternative
formats are also understood: <literal>SS</literal>,
<literal>MMSS</literal>, <literal>HHMMSS</literal>,
- <literal>HHMMSS.fraction</literal>. Note that MySQL doesn't
- (yet) store the fraction.
+ <literal>HHMMSS.fraction</literal>. Note that MySQL does not
+ store the fraction part.
</para>
</listitem>
@@ -3428,19 +3429,16 @@
<para>
<literal>ORDER BY</literal> properly sorts
- <literal>TIMESTAMP</literal> or <literal>YEAR</literal> values
- that have two-digit years.
+ <literal>YEAR</literal> values that have two-digit years.
</para>
<para>
Some functions like <literal>MIN()</literal> and
- <literal>MAX()</literal> convert a <literal>TIMESTAMP</literal>
- or <literal>YEAR</literal> to a number. This means that a value
- with a two-digit year does not work properly with these
- functions. The fix in this case is to convert the
- <literal>TIMESTAMP</literal> or <literal>YEAR</literal> to
- four-digit year format or use something like
- <literal>MIN(DATE_ADD(timestamp,INTERVAL 0 DAY))</literal>.
+ <literal>MAX()</literal> convert a <literal>YEAR</literal> to a
+ number. This means that a value with a two-digit year does not
+ work properly with these functions. The fix in this case is to
+ convert the <literal>TIMESTAMP</literal> or
+ <literal>YEAR</literal> to four-digit year format.
</para>
</section>
@@ -3864,12 +3862,12 @@
<para>
You should consider the preceding padding and stripping
- characteristics carefully if you plan to use these data types
- for storing binary data and you require that the value retrieved
- be exactly the same as the value stored. The following example
- illustrates how <literal>0x00</literal>-padding of
- <literal>BINARY</literal> values affects column value
- comparisons:
+ characteristics carefully if you plan to use the
+ <literal>BINARY</literal> data type for storing binary data and
+ you require that the value retrieved be exactly the same as the
+ value stored. The following example illustrates how
+ <literal>0x00</literal>-padding of <literal>BINARY</literal>
+ values affects column value comparisons:
</para>
<programlisting>
@@ -3894,12 +3892,13 @@
<para>
If the value retrieved must be the same as the value specified
- for storage with no padding, it might be preferable to use one
- of the <literal>BLOB</literal> data types instead.
+ for storage with no padding, it might be preferable to use
+ <literal>VARBINARY</literal> or one of the
+ <literal>BLOB</literal> data types instead.
</para>
<para>
- MySQL may silently change the type of a
+ 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"/>.
@@ -3998,7 +3997,7 @@
exceeds the data type's maximum length, the value is truncated
to fit. If the truncated characters are not spaces, a warning is
generated. You can cause an error to occur and the value to be
- rejected rather than to be truncated with awarning by using
+ rejected rather than to be truncated with a warning by using
strict SQL mode. See <xref linkend="server-sql-mode"/>.
</para>
@@ -4951,12 +4950,12 @@
< 2<superscript>32</superscript></entry>
</row>
<row>
- <entry><literal>ENUM('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',...)</literal></entry>
+ <entry><literal>ENUM('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',…)</literal></entry>
<entry>1 or 2 bytes, depending on the number of enumeration values (65,535
values maximum)</entry>
</row>
<row>
- <entry><literal>SET('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',...)</literal></entry>
+ <entry><literal>SET('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',…)</literal></entry>
<entry>1, 2, 3, 4, or 8 bytes, depending on the number of set members (64
members maximum)</entry>
</row>
@@ -5046,8 +5045,8 @@
<listitem>
<para>
- If the size of the column is 256 characters or more,
- the column requires two bytes extra storage per row.
+ If the size of the column is 256 characters or more, the
+ column requires two bytes extra storage per row.
</para>
</listitem>
Modified: trunk/refman-5.1/data-types.xml
===================================================================
--- trunk/refman-5.1/data-types.xml 2006-01-18 19:31:50 UTC (rev 904)
+++ trunk/refman-5.1/data-types.xml 2006-01-18 19:32:04 UTC (rev 905)
@@ -455,7 +455,7 @@
All arithmetic is done using signed
<literal>BIGINT</literal> or <literal>DOUBLE</literal>
- values, so you shouldn't use unsigned big integers
+ values, so you should not use unsigned big integers
larger than <literal>9223372036854775807</literal> (63
bits) except with bit functions! If you do that, some of
the last digits in the result may be wrong because of
@@ -473,8 +473,8 @@
<listitem>
<para>
- When using integers to store big unsigned values in
- a <literal>BIGINT</literal> column.
+ When using integers to store large unsigned values
+ in a <literal>BIGINT</literal> column.
</para>
</listitem>
@@ -980,18 +980,20 @@
<para>
A <literal>TIMESTAMP</literal> column is useful for
recording the date and time of an <literal>INSERT</literal>
- or <literal>UPDATE</literal> operation. The first
- <literal>TIMESTAMP</literal> column in a table is
+ or <literal>UPDATE</literal> operation. By default, the
+ first <literal>TIMESTAMP</literal> column in a table is
automatically set to the date and time of the most recent
- operation if you don't assign it a value yourself. You can
+ operation if you do not assign it a value yourself. You can
also set any <literal>TIMESTAMP</literal> column to the
current date and time by assigning it a
- <literal>NULL</literal> value.
+ <literal>NULL</literal> value. Variations on automatic
+ initialization and update properties are described in
+ <xref linkend="timestamp-4-1"/>.
</para>
<para>
A <literal>TIMESTAMP</literal> value is returned as a string
- in the format <literal>'YYYY-MM-DD HH:MM:SS'</literal>whose
+ in the format <literal>'YYYY-MM-DD HH:MM:SS'</literal> whose
display width is fixed at 19 characters. If you want to
obtain the value as a number, you should add
<literal>+0</literal> to the timestamp column.
@@ -1100,9 +1102,9 @@
</para>
<para>
- MySQL ¤t-series; string data types include some features
- that you may not have encountered in working with versions of
- MySQL prior to 4.1:
+ In MySQL 4.1 and up, string data types include some features
+ that you may not have encountered in working with previous
+ versions of MySQL (prior to 4.1):
</para>
<itemizedlist>
@@ -1111,9 +1113,10 @@
<para>
Column definitions for many string data types can include a
<literal>CHARACTER SET</literal> attribute to specify the
- character set and, optionally, a collation.
- (<literal>CHARSET</literal> is a synonym for
- <literal>CHARACTER SET</literal>.) These attributes apply to
+ character set. (<literal>CHARSET</literal> is a synonym for
+ <literal>CHARACTER SET</literal>.) The
+ <literal>COLLATE</literal> attribute specifies a collation
+ for the the character set. These attributes apply to
<literal>CHAR</literal>, <literal>VARCHAR</literal>, the
<literal>TEXT</literal> types, <literal>ENUM</literal>, and
<literal>SET</literal>. For example:
@@ -1122,8 +1125,8 @@
<programlisting>
CREATE TABLE t
(
- c1 CHAR(20) CHARACTER SET utf8,
- c2 CHAR(20) CHARACTER SET latin1 COLLATE latin1_bin
+ c1 VARCHAR(20) CHARACTER SET utf8,
+ c2 TEXT CHARACTER SET latin1 COLLATE latin1_general_cs
);
</programlisting>
@@ -1132,17 +1135,16 @@
<literal>c1</literal> that has a character set of
<literal>utf8</literal> with the default collation for that
character set, and a column named <literal>c2</literal> that
- has a character set of <literal>latin1</literal> and the
- binary collation for the character set. The binary collation
- is not case sensitive.
+ has a character set of <literal>latin1</literal> and a
+ case-sensitive collation.
</para>
</listitem>
<listitem>
<para>
MySQL ¤t-series; interprets length specifications in
- character column definitions in character units. (Some
- earlier MySQL versions interpreted lengths in bytes.)
+ character column definitions in character units.
+ (Previously, MySQL interpreted lengths in bytes.)
</para>
</listitem>
@@ -1152,27 +1154,30 @@
the <literal>TEXT</literal> types, the
<literal>BINARY</literal> attribute causes the column to be
assigned the binary collation of the column character set.
+ (Previously, <literal>BINARY</literal> caused a column to
+ store binary strings.)
</para>
</listitem>
<listitem>
<para>
Character column sorting and comparison are based on the
- character set assigned to the column. For earlier versions,
- sorting and comparison are based on the collation of the
- server character set. For <literal>CHAR</literal> and
+ character set assigned to the column. (Previously, sorting
+ and comparison were based on the collation of the server
+ character set.) For <literal>CHAR</literal> and
<literal>VARCHAR</literal> columns, you can declare the
- column with the <literal>BINARY</literal> attribute to cause
- sorting and comparison to use the underlying character code
- values rather then a lexical ordering.
+ column with a binary collation or the
+ <literal>BINARY</literal> attribute to cause sorting and
+ comparison to use the underlying character code values
+ rather than a lexical ordering.
</para>
</listitem>
</itemizedlist>
<para>
- For more about character set support in MySQL ¤t-series;,
- see <xref linkend="charset"/>.
+ <xref linkend="charset"/>, provides additional information about
+ use of character sets in MySQL.
</para>
<itemizedlist>
@@ -1722,7 +1727,7 @@
<secondary>ENUM</secondary>
</indexterm>
- <literal>ENUM('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',...)</literal>
+ <literal>ENUM('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',…)</literal>
</para>
<para>
@@ -1730,7 +1735,7 @@
value, chosen from the list of values
<literal>'<replaceable>value1</replaceable>'</literal>,
<literal>'<replaceable>value2</replaceable>'</literal>,
- <literal>...</literal>, <literal>NULL</literal> or the
+ <literal>…</literal>, <literal>NULL</literal> or the
special <literal>''</literal> error value. An
<literal>ENUM</literal> column can have a maximum of 65,535
distinct values. <literal>ENUM</literal> values are
@@ -1755,7 +1760,7 @@
<secondary>SET</secondary>
</indexterm>
- <literal>SET('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',...)</literal>
+ <literal>SET('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',…)</literal>
</para>
<para>
@@ -1763,9 +1768,9 @@
each of which must be chosen from the list of values
<literal>'<replaceable>value1</replaceable>'</literal>,
<literal>'<replaceable>value2</replaceable>'</literal>,
- <literal>...</literal> A <literal>SET</literal> column can
- have a maximum of 64 members. <literal>SET</literal> values
- are represented internally as integers.
+ <literal>…</literal> A <literal>SET</literal> column
+ can have a maximum of 64 members. <literal>SET</literal>
+ values are represented internally as integers.
</para>
<remark role="help-description-end"/>
@@ -2188,7 +2193,7 @@
zero because MySQL allows you to store dates where the day or
month and day are zero in a <literal>DATE</literal> or
<literal>DATETIME</literal> column. This is extremely useful for
- applications that need to store a birthdate for which you don't
+ applications that need to store a birthdate for which you do not
know the exact date. In this case, you simply store the date as
<literal>'1999-00-00'</literal> or
<literal>'1999-01-00'</literal>. If you store dates such as these,
@@ -2315,7 +2320,7 @@
</row>
<row>
<entry><literal>TIMESTAMP</literal></entry>
- <entry><literal>00000000000000</literal></entry>
+ <entry><literal>'0000-00-00 00:00:00'</literal></entry>
</row>
<row>
<entry><literal>TIME</literal></entry>
@@ -2988,10 +2993,6 @@
);
</programlisting>
- <remark>
- Updated following to fix Bug#10104
- </remark>
-
<para>
If the <literal>NULL</literal> attribute is not specified,
setting the column to <literal>NULL</literal> sets it to the
@@ -3013,9 +3014,9 @@
</programlisting>
<para>
- Otherwise - that is, if the <literal>TIMESTAMP</literal>
+ Otherwise — that is, if the <literal>TIMESTAMP</literal>
column is defined using <literal>NULL</literal> but not using
- <literal>DEFAULT TIMESTAMP</literal>, as shown here...
+ <literal>DEFAULT TIMESTAMP</literal>, as shown here…
</para>
<programlisting>
@@ -3024,8 +3025,8 @@
</programlisting>
<para>
- ...then you must explicitly insert a value corresponding to
- the current date and time. For example:
+ …then you must explicitly insert a value corresponding
+ to the current date and time. For example:
</para>
<programlisting>
@@ -3082,7 +3083,7 @@
HH:MM'</literal>, <literal>'D HH'</literal>, or
<literal>'SS'</literal>. Here <literal>D</literal>
represents days and can have a value from 0 to 34. Note that
- MySQL does not (yet) store the fraction.
+ MySQL does not store the fraction part.
</para>
</listitem>
@@ -3105,8 +3106,8 @@
<literal>'10:11:12'</literal>. The following alternative
formats are also understood: <literal>SS</literal>,
<literal>MMSS</literal>, <literal>HHMMSS</literal>,
- <literal>HHMMSS.fraction</literal>. Note that MySQL doesn't
- (yet) store the fraction.
+ <literal>HHMMSS.fraction</literal>. Note that MySQL does not
+ store the fraction part.
</para>
</listitem>
@@ -3324,19 +3325,16 @@
<para>
<literal>ORDER BY</literal> properly sorts
- <literal>TIMESTAMP</literal> or <literal>YEAR</literal> values
- that have two-digit years.
+ <literal>YEAR</literal> values that have two-digit years.
</para>
<para>
Some functions like <literal>MIN()</literal> and
- <literal>MAX()</literal> convert a <literal>TIMESTAMP</literal>
- or <literal>YEAR</literal> to a number. This means that a value
- with a two-digit year does not work properly with these
- functions. The fix in this case is to convert the
- <literal>TIMESTAMP</literal> or <literal>YEAR</literal> to
- four-digit year format or use something like
- <literal>MIN(DATE_ADD(timestamp,INTERVAL 0 DAY))</literal>.
+ <literal>MAX()</literal> convert a <literal>YEAR</literal> to a
+ number. This means that a value with a two-digit year does not
+ work properly with these functions. The fix in this case is to
+ convert the <literal>TIMESTAMP</literal> or
+ <literal>YEAR</literal> to four-digit year format.
</para>
</section>
@@ -3705,12 +3703,12 @@
<para>
You should consider the preceding padding and stripping
- characteristics carefully if you plan to use these data types
- for storing binary data and you require that the value retrieved
- be exactly the same as the value stored. The following example
- illustrates how <literal>0x00</literal>-padding of
- <literal>BINARY</literal> values affects column value
- comparisons:
+ characteristics carefully if you plan to use the
+ <literal>BINARY</literal> data type for storing binary data and
+ you require that the value retrieved be exactly the same as the
+ value stored. The following example illustrates how
+ <literal>0x00</literal>-padding of <literal>BINARY</literal>
+ values affects column value comparisons:
</para>
<programlisting>
@@ -3735,17 +3733,11 @@
<para>
If the value retrieved must be the same as the value specified
- for storage with no padding, it might be preferable to use one
- of the <literal>BLOB</literal> data types instead.
+ for storage with no padding, it might be preferable to use
+ <literal>VARBINARY</literal> or one of the
+ <literal>BLOB</literal> data types instead.
</para>
- <para>
- 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">
@@ -3839,10 +3831,8 @@
exceeds the data type's maximum length, the value is truncated
to fit. If the truncated characters are not spaces, a warning is
generated. You can cause an error to occur and the value to be
- rejected rather than to be truncated with awarning by using
- strict SQL mode. See
- <xref
- linkend="server-sql-mode"/>.
+ rejected rather than to be truncated with a warning by using
+ strict SQL mode. See <xref linkend="server-sql-mode"/>.
</para>
<para>
@@ -3859,22 +3849,6 @@
<listitem>
<para>
- There is no trailing-space removal for
- <literal>BLOB</literal> and <literal>TEXT</literal> columns
- when values are stored or retrieved. (This is the same as
- with <literal>VARBINARY</literal> and
- <literal>VARCHAR</literal> columns.)
- </para>
-
- <para>
- Note that <literal>TEXT</literal> is on comparison space
- extended to fit the compared object, exactly like
- <literal>CHAR</literal> and <literal>VARCHAR</literal>.
- </para>
- </listitem>
-
- <listitem>
- <para>
For indexes on <literal>BLOB</literal> and
<literal>TEXT</literal> columns, you must specify an index
prefix length. For <literal>CHAR</literal> and
@@ -4776,12 +4750,12 @@
< 2<superscript>32</superscript></entry>
</row>
<row>
- <entry><literal>ENUM('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',...)</literal></entry>
+ <entry><literal>ENUM('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',…)</literal></entry>
<entry>1 or 2 bytes, depending on the number of enumeration values (65,535
values maximum)</entry>
</row>
<row>
- <entry><literal>SET('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',...)</literal></entry>
+ <entry><literal>SET('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',…)</literal></entry>
<entry>1, 2, 3, 4, or 8 bytes, depending on the number of set members (64
members maximum)</entry>
</row>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r905 - in trunk: . refman-4.1 refman-5.0 refman-5.1 | paul | 18 Jan |
