1. 22 Mar, 2007 18 commits
    • unknown's avatar
      sql_view.cc: · 3548ccc9
      unknown authored
        Post-fix for bug#26813.
      
      
      sql/sql_view.cc:
        Post-fix for bug#26813.
      3548ccc9
    • unknown's avatar
      Merge epotemkin@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · c7831e89
      unknown authored
      into  moonbone.local:/mnt/gentoo64/work/26813-bug-5.0-opt-mysql
      
      c7831e89
    • unknown's avatar
      Bug#26813: The SUPER privilege is wrongly required to alter a view created by · b6acfac5
      unknown authored
      another user.
      
      When the DEFINER clause isn't specified in the ALTER statement then it's loaded
      from the view definition. If the definer differs from the current user then
      the error is thrown because only a super-user can set other users as a definers.
      
      Now if the DEFINER clause is omitted in the ALTER VIEW statement then the
      definer from the original view is used without check.
      
      
      mysql-test/t/view_grant.test:
        Added a test case for the bug#27006: The SUPER privilege is wrongly required
        to alter a view created by another user.
      mysql-test/r/view_grant.result:
        Added a test case for the bug#27006: The SUPER privilege is wrongly required
        to alter a view created by another user.
      sql/sql_view.cc:
        Bug#26813: The SUPER privilege is wrongly required to alter a view created by
        another user.
        Now if the DEFINER clause is omitted in the ALTER VIEW statement then the
        definer from the original view is used without check.
      b6acfac5
    • unknown's avatar
      Merge gkodinov@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · a6bf4308
      unknown authored
      into  magare.gmz:/home/kgeorge/mysql/autopush/B26207-5.0-opt
      
      
      sql/sql_select.h:
        Auto merged
      a6bf4308
    • unknown's avatar
      Bug #26207: When making the key image to use · 843ce85a
      unknown authored
       in index search MySQL was not explicitly
       suppressing warnings. And if the context 
       happens to enable warnings (e.g. INSERT ..
       SELECT) the warnings resulting from converting 
       the data the key is compared to are 
       reported to the client.
       Fixed by suppressing warnings when converting
       the data to the same type as the key parts.
      
      
      mysql-test/r/insert_select.result:
        Bug #26207: test case
      mysql-test/t/insert_select.test:
        Bug #26207: test case
      sql/sql_select.h:
        Bug #26207: supress warnings when converting
          data of the same type to key buffer format.
      843ce85a
    • unknown's avatar
      Bug#24791: Union with AVG-groups generates wrong results · 2e72abed
      unknown authored
      Patch appled after doing a pull from the team tree. Additional tests had to be
      fixed
      
      
      mysql-test/r/union.result:
        Bug 24791
        
        The tests for temporary tables have been fixed. Since the call to 
        display_length(Item) was removed from the constructor for Item_type_holder, items 
        in temporary tables keep the original values of the items, rather than the magic
        numbers supplied by display_length.
      2e72abed
    • unknown's avatar
      Merge mhansson@bk-internal:/home/bk/mysql-5.0-opt · d25303d0
      unknown authored
      into  linux-st28.site:/home/martin/mysql/src/5.0o-bug24791
      
      
      sql/item.cc:
        Auto merged
      d25303d0
    • unknown's avatar
      Merge mhansson@bk-internal:/home/bk/mysql-5.0-opt · 22316ade
      unknown authored
      into  linux-st28.site:/home/martin/mysql/src/5.0o-bug24791
      
      
      sql/field.h:
        Auto merged
      sql/item_sum.cc:
        Auto merged
      22316ade
    • unknown's avatar
      Bug #24791: Union with AVG-groups generates wrong results · 86e12ec9
      unknown authored
      The problem in this bug is when we create temporary tables. When
      temporary tables are created for unions, there is some 
      inferrence being carried out regarding the type of the column.
      Whenever this column type is inferred to be REAL (i.e. FLOAT or
      DOUBLE), MySQL will always try to maintain exact precision, and
      if that is not possible (there are hardware limits, since FLOAT
      and DOUBLE are stored as approximate values) will switch to
      using approximate values. The problem here is that at this point
      the information about number of significant digits is not 
      available. Furthermore, the number of significant digits should
      be increased for the AVG function, however, this was not properly 
      handled. There are 4 parts to the problem:
      
      #1: DOUBLE and FLOAT fields don't display their proper display 
      lengths in max_display_length(). This is hard-coded as 53 for 
      DOUBLE and 24 for FLOAT. Now changed to instead return the 
      field_length.
      
      #2: Type holders for temporary tables do not preserve the 
      max_length of the Item's from which they are created, and is 
      instead reverted to the 53 and 24 from above. This causes 
      *all* fields to get non-fixed significant digits.
      
      #3: AVG function does not update max_length (display length)
      when updating number of decimals.
      
      #4: The function that switches to non-fixed number of 
      significant digits should use DBL_DIG + 2 or FLT_DIG + 2 as 
      cut-off values (Since fixed precision does not use the 'e' 
      notation)
      
      Of these points, #1 is the controversial one, but this 
      change is preferred and has been cleared with Monty. The 
      function causes quite a few unit tests to blow up and they had
      to b changed, but each one is annotated and motivated. We 
      frequently see the magical 53 and 24 give way to more relevant
      numbers.
      
      
      mysql-test/r/create.result:
        bug#24791
        
        changed test result
        
        With the changes made for FLOAT and DOUBLE, the original display
        lengths are now preserved.
      mysql-test/r/temp_table.result:
        bug#24791
        
        changed test resullt
        
        Test case added
      mysql-test/r/type_float.result:
        bug#24791
        
        changed test result
        
        delta 1: field was originally declared as DOUBLE with no display
        length, so the hardware maximum is chosen rather than 53.
        
        delta 2: fields exceed the maximum precision and thus switch to
        non-fixed significant digits
        
        delta 3: Same as above, number of decmals and significant digits
        was not specified when t3 was created.
      mysql-test/t/temp_table.test:
        bug#24791
        
        Test case
      sql/field.h:
        bug#24791
        
        The method max_display_length is reimplemented as
        
        uint32 max_display_length() { return field_length; }
        
        in Field_double and Field_float. Since all subclasses of 
        Field_real now have the same implementation of this method, the
        implementation has been moved up the hierarchy to Field_real.
      sql/item.cc:
        bug#24791
        
        We switch to a non-fixed number of significant digits
        (by setting decimals=NOT_FIXED_DECIMAL) if the calculated 
        display length is greater than the display length of a value 
        with the maximum precision. These values differ for double and 
        float, obviously.
      sql/item_sum.cc:
        bug#24791
        
        We must increase the display length accordinly whenever we 
        change number of decimal places.
      86e12ec9
    • unknown's avatar
      bug #16546 (DATETIME+0 not always coerced the same way) · aa1e73ca
      unknown authored
        fix for cast( AS DATETIME)+0 in 5.0 and above versions.
        val_real now works using val_decimal for DATETIME Items
        Superfluous val_real() methods deleted
      
      
      sql/item_timefunc.h:
        val_real() for datetime functions implemented
            as { return val_real_from_decimal(); }
            It's not a fastest possible way, but code is simple and less
            error-prone, what i belive is more important here as this part
            works unfrequently.
      aa1e73ca
    • unknown's avatar
      Merge mysql.com:/home/hf/work/mrg/mysql-4.1-opt · 1b601e64
      unknown authored
      into  mysql.com:/home/hf/work/mrg/mysql-5.0-opt
      
      
      mysql-test/t/type_datetime.test:
        Auto merged
      mysql-test/r/type_datetime.result:
        SCCS merged
      sql/item_timefunc.h:
        SCCS merged
      1b601e64
    • unknown's avatar
      bug #16546 (DATETIME + 0 not always coerced in the same way) · bd268daa
      unknown authored
        fix for cast( AS DATETIME) + 0 operation.
        I just implemented Item_datetime_typecast::val() method
        as it is usually done in other classes.
        Should be fixed more radically in 5.0
      
      
      mysql-test/r/type_datetime.result:
        result added
      mysql-test/t/type_datetime.test:
        testcase
      sql/item_timefunc.h:
        added double conversion to Item_datetime_typecast
      bd268daa
    • unknown's avatar
      Merge bk@192.168.21.1:mysql-5.0 · 4986d75a
      unknown authored
      into  mysql.com:/home/hf/work/mrg/mysql-5.0-opt
      
      
      sql/item.h:
        Auto merged
      sql/sql_base.cc:
        Auto merged
      sql/sql_select.cc:
        Auto merged
      sql/sql_yacc.yy:
        Auto merged
      4986d75a
    • unknown's avatar
      Merge mysql.com:/home/hf/work/mrg/mysql-4.1-opt · d6c46bdb
      unknown authored
      into  mysql.com:/home/hf/work/mrg/mysql-5.0-opt
      
      d6c46bdb
    • unknown's avatar
      Merge mysql.com:/home/hf/work/25492/my50-25492 · 0d91aacb
      unknown authored
      into  mysql.com:/home/hf/work/mrg/mysql-5.0-opt
      
      
      libmysqld/lib_sql.cc:
        Auto merged
      0d91aacb
    • unknown's avatar
      Merge mysql.com:/home/hf/work/25492/my41-25492 · b89a30c9
      unknown authored
      into  mysql.com:/home/hf/work/mrg/mysql-4.1-opt
      
      b89a30c9
    • unknown's avatar
      Merge mysql.com:/home/hf/work/25492/my41-25492 · 0a8a9f67
      unknown authored
      into  mysql.com:/home/hf/work/25492/my50-25492
      
      
      libmysqld/lib_sql.cc:
        merging
      0a8a9f67
    • unknown's avatar
      Fixed bug #27362: crash at evaluation of IN predicate when one · 3e950bba
      unknown authored
      of its argument happened to be a decimal expression returning
      the NULL value.
      The crash was due to the fact the function in_decimal::set did
      not take into account that val_decimal() could return 0 if 
      the decimal expression had been evaluated to NULL.  
      
      
      mysql-test/r/func_in.result:
        Added a test case for bug #27362.
      mysql-test/t/func_in.test:
        Added a test case for bug #27362.
      3e950bba
  2. 21 Mar, 2007 3 commits
    • unknown's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.0 · 5351224e
      unknown authored
      into  bodhi.local:/opt/local/work/mysql-5.0-runtime
      
      5351224e
    • unknown's avatar
      Merge epotemkin@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · aca0c227
      unknown authored
      into  moonbone.local:/mnt/gentoo64/work/23345-bug-5.0-opt-mysql
      
      aca0c227
    • unknown's avatar
      Bug#23345: Wrongly allowed INTO in a non-last select of a UNION. · 685219e1
      unknown authored
      INTO clause can be specified only for the last select of a UNION and it
      receives the result of the whole query. But it was wrongly allowed in
      non-last selects of a UNION which leads to a confusing query result.
      
      Now INTO allowed only in the last select of a UNION.
      
      
      mysql-test/t/union.test:
        Added a test case for the bug#23345: Wrongly allowed INTO in a non-last select of a UNION.
      mysql-test/r/union.result:
        Added a test case for the bug#23345: Wrongly allowed INTO in a non-last select of a UNION.
      sql/sql_yacc.yy:
        Bug#23345: Wrongly allowed INTO in a non-last select of a UNION.
        Now INTO allowed only in the last select of a UNION.
      685219e1
  3. 20 Mar, 2007 4 commits
    • unknown's avatar
      Merge olga.mysql.com:/home/igor/mysql-5.0-opt · 2151ea4e
      unknown authored
      into  olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug27257
      
      
      sql/item_sum.cc:
        Auto merged
      2151ea4e
    • unknown's avatar
      Fixed bug #27257: queries containing subqueries with COUNT(*) · 73fd6471
      unknown authored
      aggregated in outer context returned wrong results.
      This happened only if the subquery did not contain any references
      to outer fields.
      As there were no references to outer fields the subquery erroneously
      was taken for non-correlated one.
      Now any set function aggregated in outer context makes the subquery
      correlated.
      
      
      mysql-test/r/subselect.result:
        Added a test case for bug #27257.
      mysql-test/t/subselect.test:
        Added a test case for bug #27257.
      73fd6471
    • unknown's avatar
      Merge gkodinov@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · fa3f091f
      unknown authored
      into  magare.gmz:/home/kgeorge/mysql/autopush/B24484-5.0
      
      
      mysql-test/r/subselect3.result:
        Auto merged
      sql/item.h:
        Auto merged
      sql/item_sum.cc:
        Auto merged
      sql/opt_range.cc:
        Auto merged
      sql/sql_base.cc:
        Auto merged
      sql/sql_class.h:
        Auto merged
      sql/sql_insert.cc:
        Auto merged
      sql/sql_select.cc:
        Auto merged
      fa3f091f
    • unknown's avatar
      Bug #24484: · b8912903
      unknown authored
      To correctly decide which predicates can be evaluated with a given table
      the optimizer must know the exact set of tables that a predicate depends 
      on. If that mask is too wide (refer to non-existing tables) the optimizer
      can erroneously skip a predicate.
      One such case of wrong table usage mask were the aggregate functions.
      The have a all-1 mask (meaning depend on all tables, including non-existent
      ones).
      Fixed by making a real used_tables mask for the aggregates. The mask is
      constructed in the following way :
      1. OR the table dependency masks of all the arguments of the aggregate.
      2. If all the arguments of the function are from the local name resolution 
        context and it is evaluated in the same name resolution
        context where it is referenced all the tables from that name resolution 
        context are OR-ed to the dependency mask. This is to denote that an
        aggregate function depends on the number of rows it processes.
      3. Handle correctly the case of an aggregate function optimization (such that
        the aggregate function can be pre-calculated and made a constant).
      
      Made sure that an aggregate function is never a constant (unless subject of a 
      specific optimization and pre-calculation).  
      
      One other flaw was revealed and fixed in the process : references were 
      not calling the recalculation method for used_tables of their targets.
      
      
      mysql-test/r/subselect3.result:
        Bug #24484: test case
      mysql-test/t/subselect3.test:
        Bug #24484: test case
      sql/item.h:
        Bug #24484: Item_ref must update the used tables.
      sql/item_sum.cc:
        Bug #24484: correct calculation of used_tables for aggregates.
      sql/item_sum.h:
        Bug #24484: correct calculation of used_tables for aggregates.
      sql/opt_range.cc:
        Bug #24484: fixed ref resolution in loose index scan
      sql/sql_base.cc:
        Bug #24484: moved counting of leaf tables inside 
        setup_tables_and_check_access.
      sql/sql_class.h:
        Bug #24484: changed table count to more narrow type.
      sql/sql_insert.cc:
        Bug #24484: moved counting of leaf tables inside 
        setup_tables_and_check_access. Substract the first
        table (and its subtables) of an INSERT statement
        from leaf_count.
      sql/sql_select.cc:
        Bug #24484: correct check for aggregates
      b8912903
  4. 19 Mar, 2007 2 commits
    • unknown's avatar
      sql_insert.cc: · a72aa6a6
      unknown authored
        Removed wrong fix for the bug#27006.
        The bug was added by the fix for the bug#19978 and fixed by Monty on 2007/02/21.
      trigger.test, trigger.result:
        Corrected test case for the bug#27006.
      
      
      sql/sql_insert.cc:
        Removed wrong fix for the bug#27006.
        The bug was added by the fix for the bug#19978 and fixed by Monty on 2007/02/21.
      mysql-test/t/trigger.test:
        Corrected test case for the bug#27006.
      mysql-test/r/trigger.result:
        Corrected test case for the bug#27006.
      a72aa6a6
    • unknown's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.0 · 21b4c428
      unknown authored
      into  bodhi.local:/opt/local/work/mysql-5.0-runtime
      
      
      sql/field.cc:
        Auto merged
      sql/item.cc:
        Auto merged
      sql/item.h:
        Auto merged
      sql/item_func.cc:
        Auto merged
      sql/sp_head.cc:
        Auto merged
      sql/sql_base.cc:
        Auto merged
      sql/sql_select.cc:
        Auto merged
      sql/sql_show.cc:
        Auto merged
      sql/sql_table.cc:
        Auto merged
      sql/sql_yacc.yy:
        Auto merged
      mysql-test/r/sp.result:
        SCCS merged
      mysql-test/t/sp.test:
        SCCS merged
      21b4c428
  5. 16 Mar, 2007 7 commits
    • unknown's avatar
      Bug#27006: AFTER UPDATE triggers not fired with INSERT ... ON DUPLICATE KEY · 1238f850
      unknown authored
      UPDATE if the row wasn't actually changed.
      
      This bug was caused by fix for bug#19978. It causes AFTER UPDATE triggers
      not firing if a row wasn't actually changed by the update part of the
      INSERT .. ON DUPLICATE KEY UPDATE.
      
      Now triggers are always fired if a row is touched by the INSERT ... ON
      DUPLICATE KEY UPDATE.
      
      
      sql/sql_insert.cc:
        Bug#27006: AFTER UPDATE triggers not fired with INSERT ... ON DUPLICATE KEY
        UPDATE if the row wasn't actually changed.
        Now triggers are always fired if a row is touched by the INSERT ... ON
        DUPLICATE KEY UPDATE.
      mysql-test/r/trigger.result:
        Added a test case for the bug#27006: AFTER UPDATE triggers not fired with INSERT ... ON DUPLICATE KEY
        UPDATE if the row wasn't actually changed.
      mysql-test/t/trigger.test:
        Added a test case for the bug#27006: AFTER UPDATE triggers not fired with INSERT ... ON DUPLICATE KEY
        UPDATE if the row wasn't actually changed.
      1238f850
    • unknown's avatar
      Merge gkodinov@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · 0583358e
      unknown authored
      into  magare.gmz:/home/kgeorge/mysql/autopush/B26261-5.0-opt
      
      
      sql/mysql_priv.h:
        Auto merged
      sql/sql_insert.cc:
        Auto merged
      sql/sql_prepare.cc:
        Auto merged
      mysql-test/r/insert_update.result:
        SCCS merged
      mysql-test/t/insert_update.test:
        SCCS merged
      0583358e
    • unknown's avatar
      Bug #26261: · 6c2b21ba
      unknown authored
       INSERT uses query_id to verify what fields are
       mentioned in the fields list of the INSERT command.
       However the check for that is made after the 
       ON DUPLICATE KEY is processed. This causes all
       the fields mentioned in ON DUPLICATE KEY to be 
       considered as mentioned in the fields list of 
       INSERT.
       Moved the check up, right after processing the
       fields list.
      
      
      mysql-test/r/insert_update.result:
        Bug #26261: test case
      mysql-test/t/insert_update.test:
        Bug #26261: test case
      sql/mysql_priv.h:
        Bug #26261: moved the check inside mysql_prepare_insert
      sql/sql_insert.cc:
        Bug #26261: move the check inside mysql_prepare_insert
        before setting up the ON DUPLICATE KEY part
      sql/sql_prepare.cc:
        Bug #26261: moved the check inside mysql_prepare_insert
      6c2b21ba
    • unknown's avatar
      Merge sgluhov@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · ed685138
      unknown authored
      into  mysql.com:/home/gluh/MySQL/Merge/5.0-opt
      
      ed685138
    • unknown's avatar
      Bug#26285 selecting information_schema crahes server · 723bac48
      unknown authored
      The crash happens when 'skip-grant-tables' is enabled.
      We skip the filling of I_S privilege tables 
      if acl_cache is not initialized.
      
      
      mysql-test/r/skip_grants.result:
        test result
      mysql-test/t/skip_grants.test:
        test case
      sql/sql_acl.cc:
        skip filling of I_S privilege tables
        if acl_cache is not initialized
      723bac48
    • unknown's avatar
      Merge bk@192.168.21.1:mysql-5.0-opt · 0d851a4f
      unknown authored
      into  mysql.com:/home/hf/work/mrg/mysql-5.0-opt
      
      0d851a4f
    • unknown's avatar
      Merge bk@192.168.21.1:mysql-5.0 · e09cfa30
      unknown authored
      into  mysql.com:/home/hf/work/mrg/mysql-5.0-opt
      
      
      sql/sql_parse.cc:
        Auto merged
      e09cfa30
  6. 15 Mar, 2007 6 commits
    • unknown's avatar
      Raise version number after cloning 5.0.38 · fd97548d
      unknown authored
      fd97548d
    • unknown's avatar
      Merge mysql.com:/home/svoj/devel/bk/mysql-4.1-engines · c79b1f15
      unknown authored
      into  mysql.com:/home/svoj/devel/bk/mysql-5.0-engines
      
      c79b1f15
    • unknown's avatar
      Merge epotemkin@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · 1bfa0046
      unknown authored
      into  moonbone.local:/mnt/gentoo64/work/27033-bug-5.0-opt-mysql
      
      1bfa0046
    • unknown's avatar
      Bug#27033: 0 as LAST_INSERT_ID() after INSERT .. ON DUPLICATE if rows were · 5660bb85
      unknown authored
      touched but not actually changed.
      
      The LAST_INSERT_ID() is reset to 0 if no rows were inserted or changed.
      This is the case when an INSERT ... ON DUPLICATE KEY UPDATE updates a row
      with the same values as the row contains.
      
      Now the LAST_INSERT_ID() values is reset to 0 only if there were no rows
      successfully inserted or touched.
      The new 'touched' field is added to the COPY_INFO structure. It holds the
      number of rows that were touched no matter whether they were actually
      changed or not.
      
      
      sql/sql_class.h:
        Bug#27033: 0 as LAST_INSERT_ID() after INSERT .. ON DUPLICATE if rows were
        touched but not actually changed.
        
        The new 'touched' field is added to the COPY_INFO structure. It holds the
        number of rows that were touched no matter whether they were actually
        changed or not.
      mysql-test/r/insert_update.result:
        Added a test case for the bug#27033: 0 as LAST_INSERT_ID() after INSERT .. ON DUPLICATE if rows were
        touched but not actually changed.
      mysql-test/t/insert_update.test:
        Added a test case for the bug#27033: 0 as LAST_INSERT_ID() after INSERT .. ON DUPLICATE if rows were
        touched but not actually changed.
      sql/sql_insert.cc:
        Bug#27033: 0 as LAST_INSERT_ID() after INSERT .. ON DUPLICATE if rows were
        touched but not actually changed.
        
        Now the LAST_INSERT_ID() values is reset to 0 only if there were no rows
        successfully inserted or touched.
      5660bb85
    • unknown's avatar
      Merge mysql.com:/home/hf/work/26833/my50-26833 · ddb2701d
      unknown authored
      into  mysql.com:/home/hf/work/mrg/mysql-5.0-opt
      
      
      sql/sql_parse.cc:
        Auto merged
      ddb2701d
    • unknown's avatar
      Merge bk@192.168.21.1:mysql-5.0 · 6ae76968
      unknown authored
      into  mysql.com:/home/hf/work/mrg/mysql-5.0-opt
      
      
      mysql-test/r/gis-rtree.result:
        Auto merged
      6ae76968