1. 16 May, 2008 6 commits
  2. 15 May, 2008 1 commit
    • cmiller@zippy.cornsilk.net's avatar
      Bug#36570: Parse error of CREATE PROCEDURE stmt with comments on \ · 573828aa
      cmiller@zippy.cornsilk.net authored
      	slave
      
      The stored-routine code took the contents of the (lowest) parser
      and copied it directly to the binlog, which causes problems if there
      is a special case of interpretation at the parser level -- which 
      there is, in the "/*!VER */" comments.  The trailing "*/" caused
      errors on the slave, naturally.
      
      Now, since by that point we have /properly/ created parse-tree (as 
      the rest of the server should do!) for the stored-routine CREATE, we
      can construct a perfect statement from that information, instead of
      writing uncertain information from an unknown parser state.  
      Fortunately, there's already a function nearby that does exactly 
      that.
      ---
      Update for Bug#36570.  Qualify routine names with db name when
      writing to the binlog ONLY if the source text is qualified.
      573828aa
  3. 14 May, 2008 1 commit
  4. 13 May, 2008 3 commits
  5. 12 May, 2008 2 commits
    • gshchepa/uchum@host.loc's avatar
      Merge host.loc:/work/bugs/5.0-bugteam-36055 · 486ef1ba
      gshchepa/uchum@host.loc authored
      into  host.loc:/work/bk/5.0-bugteam
      486ef1ba
    • gshchepa/uchum@host.loc's avatar
      Fixed bug #36055: mysql_upgrade doesn't really 'upgrade' tables · 1e7be565
      gshchepa/uchum@host.loc authored
      The REPAIR TABLE ... USE_FRM query silently corrupts data of tables
      with old .FRM file version.
      The mysql_upgrade client program or the REPAIR TABLE query (without
      the USE_FRM clause) can't prevent this trouble, because in the
      common case they don't upgrade .FRM file to compatible structure.
      
      1. Evaluation of the REPAIR TABLE ... USE_FRM query has been
         modified to reject such tables with the message:
         "Failed repairing incompatible .FRM file".
      
      2. REPAIR TABLE query (without USE_FRM clause) evaluation has been
         modified to upgrade .FRM files to current version.
      
      3. CHECK TABLE ... FOR UPGRADE query evaluation has been modified
         to return error status when .FRM file has incompatible version.
      
      4. mysql_upgrade and mysqlcheck client programs call CHECK TABLE
         FOR UPGRADE and REPAIR TABLE queries, so their behaviors have
         been changed too to upgrade .FRM files with incompatible
         version numbers.
      1e7be565
  6. 08 May, 2008 2 commits
  7. 06 May, 2008 3 commits
  8. 05 May, 2008 1 commit
  9. 02 May, 2008 5 commits
  10. 01 May, 2008 4 commits
  11. 30 Apr, 2008 1 commit
  12. 28 Apr, 2008 8 commits
  13. 24 Apr, 2008 2 commits
    • evgen@moonbone.local's avatar
      Bug#36023: Incorrect handling of zero length caused an assertion to fail. · e9e66793
      evgen@moonbone.local authored
      When a zero length is provided to the my_decimal_length_to_precision
      function along with unsigned_flag set to false it returns a negative value.
      For queries that employs temporary tables may cause failed assertion or
      excessive memory consumption while temporary table creation.
      
      Now the my_decimal_length_to_precision and the my_decimal_precision_to_length
      functions take unsigned_flag into account only if the length/precision
      argument is non-zero.
      e9e66793
    • mleich@five.local.lan's avatar
      Fix for funcs_1 tests which fail in 5.0.60 · f8a3ad59
      mleich@five.local.lan authored
      This is basically a backport of changes (only a few were missing)
      which were already pushed to 5.0-build and upmerged to
      5.1-build, 6.0-build
      f8a3ad59
  14. 23 Apr, 2008 1 commit
    • kent@mysql.com/kent-amd64.(none)'s avatar
      Many files: [Changes done by mleich] · 3cf72be6
      kent@mysql.com/kent-amd64.(none) authored
        Fix for
           Bug#35335 funcs_1: Some tests fail within load_file during
                              pushbuild runs
           Solution: 1. Move files with input data used in load_file,
                        load data etc.
                        from suite/funcs_1/<whatever>
                        to std_data
                     2. Use for testsuite funcs_1 the server option
                        --secure-file-priv=<MYSQLTEST_VARDIR>
                     3. Outfiles have to be stored under MYSQLTEST_VARDIR
        + changes according to WL#4304 Cleanup in funcs_1 tests
          - backport of fixes/improvements made in 5.1 to 5.0
            The differences between scripts in 5.0 and 5.1 cause
            much additional and annoying work during any upmerge.
          - replace error numbers with names
          - improved comments
          - improved formatting
          - Unify storage engine names so that result files for
            storage engine variants do not differ (some tests)
          - remove a script no more used (tests are done in other scripts)
      3cf72be6