MySQL Lists are EOL. Please join:

List:Internals« Previous MessageNext Message »
From:jon Date:October 7 2005 9:00am
Subject:bk commit - mysqldoc@docsrva tree (jon:1.3676)
View as plain text  
Below is the list of changes that have just been committed into a local
mysqldoc repository of jon. When jon 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.3676 05/10/07 19:00:42 jon@stripped +4 -0
  5.1 version edits to Installation chapter.
  
  Cut Installation sections referencing 4.1.
  
  Fixed link in Intro broken by removal of section.
  
  Updated Status file.
  
  Updated deleted-sections file.

  refman-5.1/introduction.xml
    1.23 05/10/07 19:00:41 jon@stripped +3 -2
    Fixed broken link.

  refman-5.1/installing.xml
    1.28 05/10/07 19:00:41 jon@stripped +18 -697
    5.1 version edits.
    (Cut sections downgrading-to-4-1 and
    upgrading-from-4-1.)

  refman-5.1/deleted-sections.txt
    1.3 05/10/07 19:00:41 jon@stripped +2 -0
    Added IDs of sections deleted from 5.1 Installation chapter.

  refman-5.1/Status
    1.13 05/10/07 19:00:40 jon@stripped +2 -2
    Updating...

# 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:	jon
# Host:	ghidora.site
# Root:	/home/jon/bk/mysqldoc

--- 1.12/refman-5.1/Status	2005-10-07 15:03:41 +10:00
+++ 1.13/refman-5.1/Status	2005-10-07 19:00:40 +10:00
@@ -7,7 +7,8 @@
     charset 
     sql-syntax
     news
-    partition (writing in progress)
+    installing
+    partitioning (writing in progress)
 
 - 5.1 chapters awaiting major edits:
     preface
@@ -17,7 +18,6 @@
     language-structure  
     storage-engines
     replication
-    installing
     client-side-scripts
     innodb
     limits

--- 1.2/refman-5.1/deleted-sections.txt	2005-10-04 05:49:08 +10:00
+++ 1.3/refman-5.1/deleted-sections.txt	2005-10-07 19:00:41 +10:00
@@ -15,6 +15,7 @@
 
 # from installing.xml:
 
+upgrading-from-4-1
 upgrading-from-4-0
 upgrading-from-3-23
 upgrading-from-3-22
@@ -22,6 +23,7 @@
 upgrading-from-3-20
 
 downgrading-to-4-0
+downgrading-to-4-1
 
 # from news.xml:
 

--- 1.27/refman-5.1/installing.xml	2005-09-18 10:13:23 +10:00
+++ 1.28/refman-5.1/installing.xml	2005-10-07 19:00:41 +10:00
@@ -1181,8 +1181,8 @@
             <para>
               Before we start to build a new MySQL release, we ensure
               that all reported repeatable bugs for that MySQL version
-              (3.23.x, 4.0.x, 4.1.x, 5.0.x, and so on) are fixed. If
-              something is impossible to fix (due to some internal
+              (3.23.x, 4.0.x, 4.1.x, 5.0.x, 5.1.x, and so on) are fixed.
+              If something is impossible to fix (due to some internal
               design decision in MySQL), we document this in the manual.
               See <xref linkend="bugs"/>.
             </para>
@@ -4351,7 +4351,7 @@
           <para>
             The installation or data directory locations are different
             from the default locations (<filename>C:\Program
-            Files\MySQL\MySQL Server 5.0</filename> and
+            Files\MySQL\MySQL Server &current-series;</filename> and 
             <filename>C:\Program Files\MySQL\MySQL Server
             &current-series;\data</filename>).
           </para>
@@ -5026,16 +5026,13 @@
             <option>--defaults-file</option>, but this is discouraged.
             <option>--defaults-file</option> is more flexible because it
             enables you to specify multiple startup options for the
-            server by placing them in the named option file. Also, in
-            MySQL &current-series;, use of an option different from
-            <option>--defaults-file</option> is not supported until
-            5.0.3.
+            server by placing them in the named option file.
           </para>
         </listitem>
 
         <listitem>
           <para>
-            As of MySQL 5.0.1, you can also specify a
+            In MySQL &current-series;, you can also specify a
             <option>--local-service</option> option following the
             service name. This causes the server to run using the
             <literal>LocalService</literal> Windows account that has
@@ -8229,9 +8226,9 @@
 
         <listitem>
           <para>
-            It is now possible to build MySQL &current-series; with big
+            It is possible to build MySQL &current-series; with big
             table support using the <option>--with-big-tables</option>
-            option, beginning with MySQL 5.0.4.
+            option.
           </para>
 
           <para>
@@ -11962,7 +11959,7 @@
       <listitem>
         <para>
           Before upgrading from MySQL &previous-series; to
-          &current-series;, read <xref linkend="upgrading-from-4-1"/>)
+          &current-series;, read <xref linkend="upgrading-from-5-0"/>,
           as well as <xref linkend="news"/>. These provide information
           about features that are new or different in MySQL
           &current-series; as opposed to those found in MySQL
@@ -12099,550 +12096,7 @@
         <xref linkend="upgrading-grant-tables"/>.
       </para>
 
-    </section>
-
-    <section id="upgrading-from-4-1">
-
-      <title id="title-upgrading-from-4-1">&title-upgrading-from-4-1;</title>
-
-      <indexterm>
-        <primary>compatibility</primary>
-        <secondary>between MySQL versions</secondary>
-      </indexterm>
-
-      <indexterm>
-        <primary>upgrading</primary>
-        <secondary>to 5.0</secondary>
-      </indexterm>
-
-      <para>
-        <emphasis role="bold">Note</emphasis>: Currently, MySQL
-        &current-series; is at Beta status and, as for any other
-        pre-production release, should not be installed on
-        production-level systems or systems with critical data. It is
-        good practice to back up your data before installing any new
-        version of software. Although MySQL has done its best to ensure
-        a high level of quality, you should protect your data by making
-        a backup as you would for any software beta release.
-      </para>
-
-      <para>
-        In general, you should do the following when upgrading to MySQL
-        &current-series; from &previous-series;:
-      </para>
-
-      <itemizedlist>
-
-        <listitem>
-          <para>
-            Check the items in the change list found later in this
-            section to see whether any of them might affect your
-            applications. Note particularly any that are marked
-            <emphasis role="bold">Incompatible change</emphasis>; these
-            result in incompatibilities with earlier versions of MySQL,
-            and may require your attention <emphasis>before you
-            upgrade</emphasis>.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            Read the MySQL 5.1 change history to see what significant
-            new features you can use in 5.1. See
-            <xref linkend="news-5-1-x"/>.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            If you are running MySQL Server on Windows, see
-            <xref linkend="windows-upgrading"/>. You should also be
-            aware that two of the Windows MySQL servers were renamed.
-            See <xref linkend="windows-select-server"/>.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            MySQL 5.0 adds support for stored procedures. This support
-            requires the <literal>proc</literal> table in the
-            <literal>mysql</literal> database. To create this file, you
-            should run the <command>mysql_fix_privilege_tables</command>
-            script as described in
-            <xref linkend="upgrading-grant-tables"/>.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            MySQL 5.0 adds support for views. This support requires
-            extra privilege columns in the <literal>user</literal> and
-            <literal>db</literal> tables in the <literal>mysql</literal>
-            database. To create these columns, you should run the
-            <command>mysql_fix_privilege_tables</command> script as
-            described in <xref linkend="upgrading-grant-tables"/>.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            If you are using replication, see
-            <xref linkend="replication-upgrade"/> for information on
-            upgrading your replication setup.
-          </para>
-        </listitem>
-
-      </itemizedlist>
-
-      <para>
-        Several visible behaviors have changed between MySQL
-        &previous-series; and MySQL &current-series; to make MySQL more
-        compatible with standard SQL. These changes may affect your
-        applications.
-      </para>
-
-      <para>
-        The following list describes changes that may affect
-        applications and that you should watch out for when upgrading to
-        version 5.0.
-      </para>
-
-      <para>
-        <emphasis role="bold">Server Changes:</emphasis>
-      </para>
-
-      <itemizedlist>
-
-        <listitem>
-          <para>
-            <emphasis role="bold">Incompatible change</emphasis>: The
-            indexing order for end-space in <literal>TEXT</literal>
-            columns for <literal>InnoDB</literal> and
-            <literal>MyISAM</literal> tables has changed. Starting from
-            5.0.3, <literal>TEXT</literal> indexes are compared as
-            space-padded at the end (just as MySQL sorts
-            <literal>CHAR</literal>, <literal>VARCHAR</literal> and
-            <literal>TEXT</literal> fields). If you have a index on a
-            <literal>TEXT</literal> column, you should run
-            <literal>CHECK TABLE</literal> on it. If the check reports
-            errors, rebuild the indexes: Dump and reload the table if it
-            is an <literal>InnoDB</literal> table, or run
-            <literal>OPTIMIZE TABLE</literal> or <literal>REPAIR
-            TABLE</literal> if it is a <literal>MyISAM</literal> table.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            <emphasis role="bold">Incompatible change</emphasis>:
-            <literal>MyISAM</literal> and <literal>InnoDB</literal>
-            tables created with <literal>DECIMAL</literal> columns in
-            MySQL 5.0.3 to 5.0.5 will appear corrupt after an upgrade to
-            MySQL 5.0.6. Dump such tables with
-            <command>mysqldump</command> before upgrading, and then
-            reload them after upgrading. (The same incompatibility will
-            occur for these tables created in MySQL 5.0.6 after a
-            downgrade to MySQL 5.0.3 to 5.0.5.)
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            <emphasis role="bold">Incompatible change</emphasis>: As of
-            MySQL 5.0.3, the server by default no longer loads
-            user-defined functions unless they have at least one
-            auxiliary symbol (for example, an
-            <literal>xxx_init</literal> or <literal>xxx_deinit</literal>
-            symbol) defined in addition to the main function symbol.
-            This behavior can be overridden with the
-            <option>--allow-suspicious-udfs</option> option. See
-            <xref linkend="udf-security"/>.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            <emphasis role="bold">Incompatible change</emphasis>: The
-            update log was removed in MySQL 5.0. If you had enabled it
-            previously, you should enable the binary log instead.
-          </para>
-        </listitem>
-
-        <listitem>
-          <remark>
-            Paul: I've removed most references to ISAM in the 5.0
-            Edition, so we need to make sure a search for it points
-            here. /JS
-          </remark>
-
-          <para>
-            <indexterm>
-              <primary>upgrading tables</primary>
-              <secondary><literal>ISAM</literal></secondary>
-            </indexterm>
-
-            <emphasis role="bold">Incompatible change:</emphasis>
-            Support for the <literal>ISAM</literal> storage engine has
-            been removed. If you have any <literal>ISAM</literal>
-            tables, you should convert them before upgrading. For
-            example, to convert an <literal>ISAM</literal> table to use
-            the <literal>MyISAM</literal> storage engine, use this
-            statement:
-          </para>
-
-<programlisting>
-ALTER TABLE <replaceable>tbl_name</replaceable> ENGINE = MyISAM;
-</programlisting>
-
-          <para>
-            Use a similar statement for every <literal>ISAM</literal>
-            table in each of your databases.
-          </para>
-        </listitem>
-
-        <listitem>
-          <remark>
-            Paul: I've removed most references to RAID in the 5.0
-            Edition, so we need to make sure that a search for it points
-            here. /JS
-          </remark>
-
-          <para>
-            <indexterm>
-              <primary>upgrading tables</primary>
-              <secondary><literal>ISAM</literal></secondary>
-            </indexterm>
-
-            <emphasis role="bold">Incompatible change</emphasis>:
-            Support for <literal>RAID</literal> options in
-            <literal>MyISAM</literal> tables has been removed from MySQL
-            5.0. If you have tables that use these options, you should
-            convert them before upgrading. One way to do this is to dump
-            them with <command>mysqldump</command>, edit the dump file
-            to remove the <literal>RAID</literal> options in the
-            <literal>CREATE TABLE</literal> statements, and reload the
-            dump file. Another possibility is to use <literal>CREATE
-            TABLE <replaceable>new_tbl</replaceable> ... SELECT
-            <replaceable>raid_tbl</replaceable></literal> to create a
-            new tablefrom the <literal>RAID</literal> table. However,
-            the <literal>CREATE TABLE</literal> part of the statement
-            must contain sufficient information to recreate column
-            attributes as well as indexes, or column attributes may be
-            lost and indexes will not appear in the new table. See
-            <xref linkend="create-table"/>.
-          </para>
-
-          <para>
-            The <filename>.MYD</filename> files for
-            <literal>RAID</literal> tables in a given database are
-            stored under the database directory in subdirectories that
-            have names consisting of two hex digits in the range from
-            <literal>00</literal> to <literal>ff</literal>. After
-            converting all tables that use <literal>RAID</literal>
-            options, these <literal>RAID</literal>-related
-            subdirectories still will exist but can be removed. Verify
-            that they are empty, and then remove them manually. (If they
-            are not empty, there is some <literal>RAID</literal> table
-            that has not been converted.)
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            In MySQL 5.0.6, binary logging of stored routines and
-            triggers was changed. This change has implications for
-            security, replication, and data recovery, as discussed in
-            <xref linkend="stored-procedure-logging"/>.
-          </para>
-        </listitem>
-
-      </itemizedlist>
-
-      <remark>
-        Uncomment this block if any client changes are noted
-      </remark>
-
-      <remark>
-        @strong{Client Changes}: @itemize @bullet @end itemize
-      </remark>
-
-      <para>
-        <emphasis role="bold">SQL Changes:</emphasis>
-      </para>
-
-      <itemizedlist>
-
-        <listitem>
-          <para>
-            <emphasis role="bold">Incompatible change:</emphasis> The
-            namespace for triggers has changed. Previously, trigger
-            names had to be unique per table. Now they must be unique
-            within the schema (database). An implication of this change
-            is that <literal>DROP TRIGGER</literal> syntax now uses a
-            schema name instead of a table name (schema name is optional
-            and, if omitted, the current schema will be used).
-          </para>
-
-          <para>
-            When upgrading from a previous version of MySQL 5 to MySQL
-            5.0.10 or newer, you must drop all triggers and re-create
-            them or <literal>DROP TRIGGER</literal> will not work after
-            the upgrade. Here is a suggested procedure for doing this:
-          </para>
-
-          <orderedlist>
-
-            <listitem>
-              <para>
-                Upgrade to MySQL 5.0.10 to be able to access trigger
-                information in the
-                <literal>INFORMATION_SCHEMA.TRIGGERS</literal> table.
-                (It should work even for pre-5.0.10 triggers.)
-              </para>
-            </listitem>
-
-            <listitem>
-              <para>
-                Dump all trigger definitions using the following
-                <literal>SELECT</literal> statement:
-              </para>
-
-<programlisting>
-SELECT CONCAT('CREATE TRIGGER ', t.TRIGGER_SCHEMA, '.', t.TRIGGER_NAME,
-              ' ', t.ACTION_TIMING, ' ', t.EVENT_MANIPULATION , ' ON ',
-              t.EVENT_OBJECT_SCHEMA, '.', t.EVENT_OBJECT_TABLE,
-              ' FOR EACH ROW ', t.ACTION_STATEMENT, '//' )
-INTO OUTFILE '/tmp/triggers.sql'
-FROM INFORMATION_SCHEMA.TRIGGERS AS t;
-</programlisting>
-
-              <para>
-                The statement uses <literal>INTO OUTFILE</literal>, so
-                you must have the <literal>FILE</literal> privilege. The
-                file will be created on the server host; use a different
-                filename if you like. To be 100% safe, inspect the
-                trigger definitions in the
-                <filename>triggers.sql</filename> file, and perhaps make
-                a backup of the file.
-              </para>
-            </listitem>
-
-            <listitem>
-              <para>
-                Stop the server and drop all triggers by removing all
-                <filename>.TRG</filename> files in your database
-                directories. Change location to your data directory and
-                issue this command:
-              </para>
-
-<programlisting>
-shell&gt; <userinput>rm */*.TRG</userinput>
-</programlisting>
-            </listitem>
-
-            <listitem>
-              <para>
-                Start the server and recreate all triggers using the
-                <filename>triggers.sql</filename> file: For example in
-                my case it was:
-              </para>
-
-<programlisting>
-mysql&gt; <userinput>delimiter // ;</userinput>
-mysql&gt; <userinput>source /tmp/triggers.sql //</userinput>
-</programlisting>
-            </listitem>
-
-            <listitem>
-              <para>
-                Check that all triggers were successfully created using
-                the <filename>SHOW TRIGGERS</filename> statement.
-              </para>
-            </listitem>
-
-          </orderedlist>
-        </listitem>
-
-        <listitem>
-          <para>
-            <emphasis role="bold">Note</emphasis>: As of MySQL 5.0.12,
-            natural joins and joins with <literal>USING</literal>,
-            including outer join variants, are processed according to
-            the SQL:2003 standard. This change may necessitate that
-            certain queries be rewritten. For example, the following
-            query will work as written before 5.0.12, but as of 5.0.12
-            will fail with an <literal>Unknown column 't1.id' in 'on
-            clause' </literal> error:
-          </para>
-
-<programlisting>
-SELECT t1.id,t2.id,t3.id FROM t1,t2 LEFT JOIN t3 ON (t3.id=t1.id)
-WHERE t1.id=t2.id;
-</programlisting>
-
-          <para>
-            To rewrite the query, use parentheses to group the tables in
-            the inner join:
-          </para>
-
-<programlisting>
-SELECT t1.id,t2.id,t3.id FROM (t1,t2) LEFT JOIN t3 ON (t3.id=t1.id)
-WHERE t1.id=t2.id; 
-</programlisting>
-
-          <para>
-            For that particular query, it is also possible to rewrite it
-            as a natural join:
-          </para>
-
-<programlisting>
-SELECT t1.id,t2.id,t3.id FROM t1,t2 NATURAL LEFT JOIN t3
-WHERE t1.id=t2.id;
-</programlisting>
-        </listitem>
-
-        <listitem>
-          <para>
-            <literal>DECIMAL</literal> columns now are stored in a more
-            efficient format. To convert a table to use the new
-            <literal>DECIMAL</literal> type, you should do an
-            <literal>ALTER TABLE</literal> on it. The <literal>ALTER
-            TABLE</literal> also will change the table's
-            <literal>VARCHAR</literal> columns to use the new
-            <literal>VARCHAR</literal> column type. For information
-            about possible incompatibilities with old applications, see
-            <xref linkend="precision-math"/>.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            MySQL 5.0.3 and up uses precision math when calculating with
-            <literal>DECIMAL</literal> values (64 decimal digits) and
-            for rounding exact-value numbers. See
-            <xref linkend="precision-math"/>.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            As of MySQL 5.0.3, trailing spaces no longer are removed
-            from values stored in <literal>VARCHAR</literal> and
-            <literal>VARBINARY</literal> columns. The maximum lengths
-            for <literal>VARCHAR</literal> and
-            <literal>VARBINARY</literal> columns in MySQL 5.0.3 and
-            later are 65,535 characters and 65,535 bytes, respectively.
-          </para>
-
-          <para>
-            <emphasis role="bold">Note</emphasis>: If you create a table
-            with new <literal>VARCHAR</literal> or
-            <literal>VARBINARY</literal> columns in MySQL 5.0.3 or
-            later, the table will not be usable if you downgrade to a
-            version older than 5.0.3. Dump the table before downgrading
-            and then reload it after downgrading.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            As of MySQL 5.0.3, <literal>BIT</literal> is a separate data
-            type, not a synonym for <literal>TINYINT(1)</literal>. See
-            <xref linkend="numeric-type-overview"/>.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            MySQL 5.0.2 adds several SQL modes that allow stricter
-            control over rejecting records that have invalid or missing
-            values. See <xref linkend="server-sql-mode"/>. See
-            <xref linkend="constraint-invalid-data"/>. If you want to
-            enable this control but continue to use MySQL's capability
-            for storing incorrect dates such as
-            <literal>'2004-02-31'</literal>, you should start the server
-            with
-            <option>--sql_mode=TRADITIONAL,ALLOW_INVALID_DATES</option>.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            As of MySQL 5.0.2, the <literal>SCHEMA</literal> and
-            <literal>SCHEMAS</literal> keywords are accepted as synonyms
-            for <literal>DATABASE</literal> and
-            <literal>DATABASES</literal>, respectively. (While
-            <quote>schemata</quote> is grammatically correct and even
-            appears in some MySQL 5.0 system database and table names,
-            it cannot be used as a key word for input.)
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            User variables are not case sensitive in MySQL
-            &current-series;. In MySQL 4.1, <literal>SET @x = 0; SET @X
-            = 1; SELECT @x;</literal> created two variables and returned
-            <literal>0</literal>. In MySQL &current-series;, it creates
-            one variable and returns <literal>1</literal>.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            A new startup option named
-            <option>innodb_table_locks</option> was added that causes
-            <literal>LOCK TABLE</literal> to also acquire InnoDB table
-            locks. This option is enabled by default. This can cause
-            deadlocks in applications that use
-            <literal>AUTOCOMMIT=1</literal> and <literal>LOCK
-            TABLES</literal>. If you application encounters deadlocks
-            after upgrading, you may need to add
-            <literal>innodb_table_locks=0</literal> to your
-            <filename>my.cnf</filename> file.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            A new startup option named
-            <option>innodb_table_locks</option> was added that causes
-            <literal>LOCK TABLE</literal> to also acquire InnoDB table
-            locks. This option is enabled by default. This can cause
-            deadlocks in applications that use
-            <literal>AUTOCOMMIT=1</literal> and <literal>LOCK
-            TABLES</literal>. If you application encounters deadlocks
-            after upgrading, you may need to add
-            <literal>innodb_table_locks=0</literal> to your
-            <filename>my.cnf</filename> file.
-          </para>
-        </listitem>
-
-      </itemizedlist>
-
-      <para>
-        <emphasis role="bold">C API Changes:</emphasis>
-      </para>
-
-      <itemizedlist>
-
-        <listitem>
-          <para>
-            The <literal>reconnect</literal> flag in the
-            <literal>MYSQL</literal> structure is set to 0 by
-            <literal>mysql_real_connect()</literal>. Only those client
-            programs which did not explicitly set this flag to 0 or 1
-            after <literal>mysql_real_connect()</literal> experience a
-            change. Having automatic reconnection enabled by default was
-            considered too dangerous (due to the fact that table locks,
-            temporary tables, user variables, and session variables are
-            lost after reconnection).
-          </para>
-        </listitem>
-
-      </itemizedlist>
-
-    </section>
+    </section>    
 
     <section id="upgrading-grant-tables">
 
@@ -12670,57 +12124,18 @@
       </para>
 
       <para>
-        If you are upgrading to MySQL 5.0.1 or later, the grant table
+        If you are upgrading from MySQL 4.1 or earlier, the grant table 
         upgrade procedure adds view-related columns for the
         <literal>CREATE VIEW</literal> and <literal>SHOW VIEW</literal>
         privileges. These privileges exist at the global and database
-        levels. Their initial values are assigned as follows:
+        levels. In such cases, the MySQL &current-series; version of
+        <command>mysql_fix_privilege_tables</command> copies the 
+        <literal>Create_priv</literal> value in the
+        <literal>user</literal> table to the
+        <literal>Create_view_priv</literal> and
+        <literal>Show_view_priv</literal> columns.
       </para>
 
-      <itemizedlist>
-
-        <listitem>
-          <para>
-            In MySQL 5.0.2 or later,
-            <command>mysql_fix_privilege_tables</command> copies the
-            <literal>Create_priv</literal> value in the
-            <literal>user</literal> table to the
-            <literal>Create_view_priv</literal> and
-            <literal>Show_view_priv</literal> columns.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            In 5.0.1, the view-related privileges are not enabled for
-            any accounts, so you cannot immediately use
-            <literal>GRANT</literal> to give them to accounts that
-            should have them. To deal with this, first connect to the
-            server as <literal>root</literal> and issue the following
-            statements to give the privileges to the
-            <literal>root</literal> accounts manually with
-            <literal>UPDATE</literal>:
-          </para>
-
-<programlisting>
-mysql&gt; <userinput>UPDATE mysql.user SET Show_view_priv = 'Y', Create_view_priv = 'Y'</userinput>
-    -&gt; <userinput>WHERE User = 'root';</userinput>
-mysql&gt; <userinput>FLUSH PRIVILEGES;</userinput>
-</programlisting>
-
-          <para>
-            After this, <literal>root</literal> can use
-            <literal>GRANT</literal> to give the view privileges to
-            other accounts. Note: You should issue the statements just
-            shown; <literal>GRANT ALL</literal> does not work at the
-            global and database levels, because <literal>GRANT</literal>
-            requires that you actually possess the privileges you are
-            granting.
-          </para>
-        </listitem>
-
-      </itemizedlist>
-
     </section>
 
     <section id="upgrading-to-arch">
@@ -12983,101 +12398,7 @@
 
     </orderedlist>
 
-    <section id="downgrading-to-4-1">
-
-      <title id="title-downgrading-to-4-1">&title-downgrading-to-4-1;</title>
-
-      <para>
-        After downgrading from MySQL 5.0, you may see the following
-        information in the <filename>mysql.err</filename> file:
-      </para>
-
-<programlisting>
-Incorrect information in file: './mysql/user.frm'
-</programlisting>
-
-      <para>
-        In this case, you can do the following:
-      </para>
-
-      <orderedlist>
-
-        <listitem>
-          <para>
-            Start MySQL 5.0.4 (or newer).
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            Run <command>mysql_fix_privilege_tables</command>, which
-            will change the <literal>mysql.user</literal> table to a
-            format that both MySQL 4.1 and 5.0 can use.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            Stop the MySQL server.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            Start MySQL 4.1.
-          </para>
-        </listitem>
-
-      </orderedlist>
-
-      <para>
-        If the preceding procedure fails, then you should be able to do
-        the following instead:
-      </para>
-
-      <orderedlist>
-
-        <listitem>
-          <para>
-            Start MySQL 5.0.4 (or newer).
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            Run <command>mysqldump --opt --add-drop-table mysql &gt;
-            /tmp/mysql.dump</command>.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            Stop the MySQL server.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            Start MySQL 4.1 with the <option>--skip-grant</option>
-            option.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            Run <command>mysql mysql &lt; /tmp/mysql.dump</command>.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            Run <command>mysqladmin flush-privileges</command>.
-          </para>
-        </listitem>
-
-      </orderedlist>
-
-    </section>
+    
 
   </section>
 
@@ -15870,7 +15191,7 @@
         </para>
 
         <para>
-          The maximum file size on an OpenSever 5.0.x system is 2GB.
+          The maximum file size on an OpenServer 5.0.x system is 2GB.
         </para>
 
         <para>

--- 1.22/refman-5.1/introduction.xml	2005-09-29 14:32:59 +10:00
+++ 1.23/refman-5.1/introduction.xml	2005-10-07 19:00:41 +10:00
@@ -68,8 +68,9 @@
 
     <listitem>
       <para>
-        For information about upgrading from a Version 4.1 release, see
-        <xref linkend="upgrading-from-4-1"/>.
+        For information about upgrading from a Version
+        &previous-series; release, see
+        <xref linkend="upgrading-from-5-0"/>.
       </para>
     </listitem>
 
Thread
bk commit - mysqldoc@docsrva tree (jon:1.3676)jon7 Oct