Author: paul
Date: 2006-04-12 19:03:14 +0200 (Wed, 12 Apr 2006)
New Revision: 1809
Log:
r9407@frost: paul | 2006-04-12 11:59:38 -0500
Fixed-row format dump/reload behavior for LOAD DATA/SELECT ... INTO OUTFILE
changed in 4.1.12/5.0.6: Declared display width is ignored. Instead a field
large enough to hold all values is used. (Bug#12564)
Modified:
trunk/
trunk/refman-4.1/installing.xml
trunk/refman-4.1/sql-syntax.xml
trunk/refman-5.0/installing.xml
trunk/refman-5.0/sql-syntax.xml
trunk/refman-5.1/sql-syntax.xml
trunk/refman-common/news-4.1.xml
trunk/refman-common/news-5.0.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:6598
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:9405
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:4334
+ 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:6598
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:9407
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:4334
Modified: trunk/refman-4.1/installing.xml
===================================================================
--- trunk/refman-4.1/installing.xml 2006-04-12 15:47:59 UTC (rev 1808)
+++ trunk/refman-4.1/installing.xml 2006-04-12 17:03:14 UTC (rev 1809)
@@ -12664,6 +12664,29 @@
<listitem>
<para>
+ <emphasis role="bold">Incompatible change:</emphasis> In
+ MySQL 4.1.12, the behavior of <literal>LOAD DATA
+ INFILE</literal> and <literal>SELECT ... INTO
+ OUTFILE</literal> has changed when the <literal>FIELDS
+ TERMINATED BY</literal> and <literal>FIELDS ENCLOSED
+ BY</literal> values both are empty. Formerly, a column was
+ read or written the display width of the column. For
+ example, <literal>INT(4)</literal> was read or written using
+ a field with a width of 4. Now columns are read and written
+ using a field width wide enough to hold all values in the
+ field. However, data files written before this change was
+ made might not be reloaded correctly with <literal>LOAD DATA
+ INFILE</literal> for MySQL 4.1.12 and up. This change also
+ affects data files read by <command>mysqlimport</command>
+ and written by <command>mysqldump --tab</command>, which use
+ <literal>LOAD DATA INFILE</literal> and <literal>SELECT ...
+ INTO OUTFILE</literal>. For more information, see
+ <xref linkend="load-data"/>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
<emphasis role="bold">Incompatible change</emphasis>: Before
MySQL 4.1.1, the statement parser was less strict and its
string-to-date conversion would ignore everything up to the
Modified: trunk/refman-4.1/sql-syntax.xml
===================================================================
--- trunk/refman-4.1/sql-syntax.xml 2006-04-12 15:47:59 UTC (rev 1808)
+++ trunk/refman-4.1/sql-syntax.xml 2006-04-12 17:03:14 UTC (rev 1809)
@@ -5551,11 +5551,13 @@
(<literal>''</literal>), a fixed-row (non-delimited) format
is used. With fixed-row format, no delimiters are used
between fields (but you can still have a line terminator).
- Instead, column values are written and read using the
- display widths of the columns. For example, if a column is
- declared as <literal>INT(7)</literal>, values for the column
- are written using seven-character fields. On input, values
- for the column are obtained by reading seven characters.
+ Instead, column values are read and written using a field
+ width wide enough to hold all values in the field. For
+ <literal>TINYINT</literal>, <literal>SMALLINT</literal>,
+ <literal>MEDIUMINT</literal>, <literal>INT</literal>, and
+ <literal>BIGINT</literal>, the field widths are 4, 6, 8, 11,
+ and 20, respectively, no matter what the declared display
+ width is.
</para>
<para>
@@ -5573,6 +5575,24 @@
that fixed-size format does not work if you are using a
multi-byte character set.
</para>
+
+ <para>
+ <emphasis role="bold">Note:</emphasis> Before MySQL 4.1.12,
+ fixed-row format used the display width of the column. For
+ example, <literal>INT(4)</literal> was read or written using
+ a field with a width of 4. However, if the column contained
+ wider values, they were dumped to their full width, leading
+ to the possibility of a <quote>ragged</quote> field holding
+ values of different widths. Using a field wide enough to
+ hold all values in the field prevents this problem. However,
+ data files written before this change was made might not be
+ reloaded correctly with <literal>LOAD DATA INFILE</literal>
+ for MySQL 4.1.12 and up. This change also affects data files
+ read by <command>mysqlimport</command> and written by
+ <command>mysqldump --tab</command>, which use <literal>LOAD
+ DATA INFILE</literal> and <literal>SELECT ... INTO
+ OUTFILE</literal>.
+ </para>
</listitem>
</itemizedlist>
Modified: trunk/refman-5.0/installing.xml
===================================================================
--- trunk/refman-5.0/installing.xml 2006-04-12 15:47:59 UTC (rev 1808)
+++ trunk/refman-5.0/installing.xml 2006-04-12 17:03:14 UTC (rev 1809)
@@ -12381,6 +12381,30 @@
<listitem>
<para>
+ <emphasis role="bold">Incompatible change:</emphasis> In
+ MySQL 4.1.12/5.0.6, the behavior of <literal>LOAD DATA
+ INFILE</literal> and <literal>SELECT ... INTO
+ OUTFILE</literal> has changed when the <literal>FIELDS
+ TERMINATED BY</literal> and <literal>FIELDS ENCLOSED
+ BY</literal> values both are empty. Formerly, a column was
+ read or written the display width of the column. For
+ example, <literal>INT(4)</literal> was read or written using
+ a field with a width of 4. Now columns are read and written
+ using a field width wide enough to hold all values in the
+ field. However, data files written before this change was
+ made might not be reloaded correctly with <literal>LOAD DATA
+ INFILE</literal> for MySQL 4.1.12/5.0.6 and up. This change
+ also affects data files read by
+ <command>mysqlimport</command> and written by
+ <command>mysqldump --tab</command>, which use <literal>LOAD
+ DATA INFILE</literal> and <literal>SELECT ... INTO
+ OUTFILE</literal>. For more information, see
+ <xref linkend="load-data"/>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
Some keywords are reserved in MySQL ¤t-series; that
were not reserved in MySQL &previous-series;. See
<xref linkend="reserved-words"/>.
Modified: trunk/refman-5.0/sql-syntax.xml
===================================================================
--- trunk/refman-5.0/sql-syntax.xml 2006-04-12 15:47:59 UTC (rev 1808)
+++ trunk/refman-5.0/sql-syntax.xml 2006-04-12 17:03:14 UTC (rev 1809)
@@ -5448,11 +5448,13 @@
(<literal>''</literal>), a fixed-row (non-delimited) format
is used. With fixed-row format, no delimiters are used
between fields (but you can still have a line terminator).
- Instead, column values are written and read using the
- display widths of the columns. For example, if a column is
- declared as <literal>INT(7)</literal>, values for the column
- are written using seven-character fields. On input, values
- for the column are obtained by reading seven characters.
+ Instead, column values are read and written using a field
+ width wide enough to hold all values in the field. For
+ <literal>TINYINT</literal>, <literal>SMALLINT</literal>,
+ <literal>MEDIUMINT</literal>, <literal>INT</literal>, and
+ <literal>BIGINT</literal>, the field widths are 4, 6, 8, 11,
+ and 20, respectively, no matter what the declared display
+ width is.
</para>
<para>
@@ -5470,6 +5472,24 @@
that fixed-size format does not work if you are using a
multi-byte character set.
</para>
+
+ <para>
+ <emphasis role="bold">Note:</emphasis> Before MySQL 5.0.6,
+ fixed-row format used the display width of the column. For
+ example, <literal>INT(4)</literal> was read or written using
+ a field with a width of 4. However, if the column contained
+ wider values, they were dumped to their full width, leading
+ to the possibility of a <quote>ragged</quote> field holding
+ values of different widths. Using a field wide enough to
+ hold all values in the field prevents this problem. However,
+ data files written before this change was made might not be
+ reloaded correctly with <literal>LOAD DATA INFILE</literal>
+ for MySQL 5.0.6 and up. This change also affects data files
+ read by <command>mysqlimport</command> and written by
+ <command>mysqldump --tab</command>, which use <literal>LOAD
+ DATA INFILE</literal> and <literal>SELECT ... INTO
+ OUTFILE</literal>.
+ </para>
</listitem>
</itemizedlist>
Modified: trunk/refman-5.1/sql-syntax.xml
===================================================================
--- trunk/refman-5.1/sql-syntax.xml 2006-04-12 15:47:59 UTC (rev 1808)
+++ trunk/refman-5.1/sql-syntax.xml 2006-04-12 17:03:14 UTC (rev 1809)
@@ -6701,11 +6701,13 @@
(<literal>''</literal>), a fixed-row (non-delimited) format
is used. With fixed-row format, no delimiters are used
between fields (but you can still have a line terminator).
- Instead, column values are written and read using the
- display widths of the columns. For example, if a column is
- declared as <literal>INT(7)</literal>, values for the column
- are written using seven-character fields. On input, values
- for the column are obtained by reading seven characters.
+ Instead, column values are read and written using a field
+ width wide enough to hold all values in the field. For
+ <literal>TINYINT</literal>, <literal>SMALLINT</literal>,
+ <literal>MEDIUMINT</literal>, <literal>INT</literal>, and
+ <literal>BIGINT</literal>, the field widths are 4, 6, 8, 11,
+ and 20, respectively, no matter what the declared display
+ width is.
</para>
<para>
Modified: trunk/refman-common/news-4.1.xml
===================================================================
--- trunk/refman-common/news-4.1.xml 2006-04-12 15:47:59 UTC (rev 1808)
+++ trunk/refman-common/news-4.1.xml 2006-04-12 17:03:14 UTC (rev 1809)
@@ -190,7 +190,7 @@
</para>
<itemizedlist>
-
+
<listitem>
<para>
<literal>NDB Cluster</literal>: In a 2-node cluster with a
@@ -199,14 +199,13 @@
to come up partitioned (<quote>split-brain</quote> issue).
(Bug #16447)
</para>
-
+
<para>
- A similar issue could occur when the cluster was first
- started with a sufficiently low value for this parameter. (Bug
- #18612)
+ A similar issue could occur when the cluster was first started
+ with a sufficiently low value for this parameter. (Bug #18612)
</para>
</listitem>
-
+
<listitem>
<para>
<literal>NDB Cluster</literal>: On systems with multiple
@@ -3916,6 +3915,28 @@
<listitem>
<para>
+ <emphasis role="bold">Incompatible change:</emphasis> The
+ behavior of <literal>LOAD DATA INFILE</literal> and
+ <literal>SELECT ... INTO OUTFILE</literal> has changed when
+ the <literal>FIELDS TERMINATED BY</literal> and
+ <literal>FIELDS ENCLOSED BY</literal> values both are empty.
+ Formerly, a column was read or written the display width of
+ the column. For example, <literal>INT(4)</literal> was read or
+ written using a field with a width of 4. Now columns are read
+ and written using a field width wide enough to hold all values
+ in the field. However, data files written before this change
+ was made might not be reloaded correctly with <literal>LOAD
+ DATA INFILE</literal> for MySQL 4.1.12 and up. This change
+ also affects data files read by <command>mysqlimport</command>
+ and written by <command>mysqldump --tab</command>, which use
+ <literal>LOAD DATA INFILE</literal> and <literal>SELECT ...
+ INTO OUTFILE</literal>. For more information, see
+ <xref linkend="load-data"/>. (Bug#12564)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
Added <option>--debug</option> option to
<command>my_print_defaults</command>.
</para>
Modified: trunk/refman-common/news-5.0.xml
===================================================================
--- trunk/refman-common/news-5.0.xml 2006-04-12 15:47:59 UTC (rev 1808)
+++ trunk/refman-common/news-5.0.xml 2006-04-12 17:03:14 UTC (rev 1809)
@@ -191,13 +191,13 @@
Uncomment following when there are new features or feature changes
to report.
</remark>
-
+
<para>
Functionality added or changed:
</para>
-
+
<itemizedlist>
-
+
<listitem>
<para>
<literal>NDB Cluster</literal>: It is now possible to perform
@@ -206,7 +206,7 @@
all configured data nodes first. (Bug #18606)
</para>
</listitem>
-
+
</itemizedlist>
<para>
@@ -214,7 +214,7 @@
</para>
<itemizedlist>
-
+
<listitem>
<para>
<literal>NDB Cluster</literal>: In a 2-node cluster with a
@@ -223,14 +223,13 @@
to come up partitioned (<quote>split-brain</quote> issue).
(Bug #16447)
</para>
-
+
<para>
- A similar issue could occur when the cluster was first
- started with a sufficiently low value for this parameter. (Bug
- #18612)
+ A similar issue could occur when the cluster was first started
+ with a sufficiently low value for this parameter. (Bug #18612)
</para>
</listitem>
-
+
<listitem>
<para>
<literal>NDB Cluster</literal>: On systems with multiple
@@ -241,7 +240,7 @@
temporary outage. (Bug #15695)
</para>
</listitem>
-
+
<listitem>
<para>
<literal>NDB Cluster</literal>: Unused open handlers for
@@ -250,7 +249,7 @@
following an <literal>ALTER TABLE</literal>. (Bug #13228)
</para>
</listitem>
-
+
<listitem>
<para>
<literal>NDB Cluster</literal>: Uninitialised internal
@@ -9392,6 +9391,28 @@
<listitem>
<para>
+ <emphasis role="bold">Incompatible change:</emphasis> The
+ behavior of <literal>LOAD DATA INFILE</literal> and
+ <literal>SELECT ... INTO OUTFILE</literal> has changed when
+ the <literal>FIELDS TERMINATED BY</literal> and
+ <literal>FIELDS ENCLOSED BY</literal> values both are empty.
+ Formerly, a column was read or written the display width of
+ the column. For example, <literal>INT(4)</literal> was read or
+ written using a field with a width of 4. Now columns are read
+ and written using a field width wide enough to hold all values
+ in the field. However, data files written before this change
+ was made might not be reloaded correctly with <literal>LOAD
+ DATA INFILE</literal> for MySQL 4.1.12 and up. This change
+ also affects data files read by <command>mysqlimport</command>
+ and written by <command>mysqldump --tab</command>, which use
+ <literal>LOAD DATA INFILE</literal> and <literal>SELECT ...
+ INTO OUTFILE</literal>. For more information, see
+ <xref linkend="load-data"/>. (Bug#12564)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
The precision of the <literal>DECIMAL</literal> data type has
been increased from 64 to 65 decimal digits.
</para>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r1809 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-common | paul | 12 Apr |
