1. 22 Mar, 2007 18 commits
    • unknown's avatar
      sql_view.cc: · 842eaa44
      unknown authored
        Post-fix for bug#26813.
      
      
      sql/sql_view.cc:
        Post-fix for bug#26813.
      842eaa44
    • unknown's avatar
      Merge epotemkin@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · 9558c66c
      unknown authored
      into  moonbone.local:/mnt/gentoo64/work/26813-bug-5.0-opt-mysql
      
      
      9558c66c
    • unknown's avatar
      Bug#26813: The SUPER privilege is wrongly required to alter a view created by · 9b774e8f
      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.
      9b774e8f
    • unknown's avatar
      Merge gkodinov@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · dc41a5ce
      unknown authored
      into  magare.gmz:/home/kgeorge/mysql/autopush/B26207-5.0-opt
      
      
      sql/sql_select.h:
        Auto merged
      dc41a5ce
    • unknown's avatar
      Bug #26207: When making the key image to use · 0a48cd93
      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.
      0a48cd93
    • unknown's avatar
      Bug#24791: Union with AVG-groups generates wrong results · 33da0f37
      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.
      33da0f37
    • unknown's avatar
      Merge mhansson@bk-internal:/home/bk/mysql-5.0-opt · a9df90a7
      unknown authored
      into  linux-st28.site:/home/martin/mysql/src/5.0o-bug24791
      
      
      sql/item.cc:
        Auto merged
      a9df90a7
    • unknown's avatar
      Merge mhansson@bk-internal:/home/bk/mysql-5.0-opt · 5b86ad19
      unknown authored
      into  linux-st28.site:/home/martin/mysql/src/5.0o-bug24791
      
      
      sql/field.h:
        Auto merged
      sql/item_sum.cc:
        Auto merged
      5b86ad19
    • unknown's avatar
      Bug #24791: Union with AVG-groups generates wrong results · aa323361
      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.
      aa323361
    • unknown's avatar
      bug #16546 (DATETIME+0 not always coerced the same way) · 2b983572
      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.
      2b983572
    • unknown's avatar
      Merge mysql.com:/home/hf/work/mrg/mysql-4.1-opt · 23354862
      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
      23354862
    • unknown's avatar
      bug #16546 (DATETIME + 0 not always coerced in the same way) · 50b5064c
      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
      50b5064c
    • unknown's avatar
      Merge bk@192.168.21.1:mysql-5.0 · 1fdab610
      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
      1fdab610
    • unknown's avatar
      Merge mysql.com:/home/hf/work/mrg/mysql-4.1-opt · 52d36629
      unknown authored
      into  mysql.com:/home/hf/work/mrg/mysql-5.0-opt
      
      
      52d36629
    • unknown's avatar
      Merge mysql.com:/home/hf/work/25492/my50-25492 · e98c61bb
      unknown authored
      into  mysql.com:/home/hf/work/mrg/mysql-5.0-opt
      
      
      libmysqld/lib_sql.cc:
        Auto merged
      e98c61bb
    • unknown's avatar
      Merge mysql.com:/home/hf/work/25492/my41-25492 · 6ef0fee8
      unknown authored
      into  mysql.com:/home/hf/work/mrg/mysql-4.1-opt
      
      
      6ef0fee8
    • unknown's avatar
      Merge mysql.com:/home/hf/work/25492/my41-25492 · b745f117
      unknown authored
      into  mysql.com:/home/hf/work/25492/my50-25492
      
      
      libmysqld/lib_sql.cc:
        merging
      b745f117
    • unknown's avatar
      Fixed bug #27362: crash at evaluation of IN predicate when one · a4a23fb9
      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.
      a4a23fb9
  2. 21 Mar, 2007 3 commits
    • unknown's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.0 · 54a0f623
      unknown authored
      into  bodhi.local:/opt/local/work/mysql-5.0-runtime
      
      
      54a0f623
    • unknown's avatar
      Merge epotemkin@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · b70693f5
      unknown authored
      into  moonbone.local:/mnt/gentoo64/work/23345-bug-5.0-opt-mysql
      
      
      b70693f5
    • unknown's avatar
      Bug#23345: Wrongly allowed INTO in a non-last select of a UNION. · 16404523
      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.
      16404523
  3. 20 Mar, 2007 4 commits
    • unknown's avatar
      Merge olga.mysql.com:/home/igor/mysql-5.0-opt · 2fd63201
      unknown authored
      into  olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug27257
      
      
      sql/item_sum.cc:
        Auto merged
      2fd63201
    • unknown's avatar
      Fixed bug #27257: queries containing subqueries with COUNT(*) · 91f7f318
      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.
      91f7f318
    • unknown's avatar
      Merge gkodinov@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · bac27bb9
      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
      bac27bb9
    • unknown's avatar
      Bug #24484: · 9c89dd65
      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
      9c89dd65
  4. 19 Mar, 2007 2 commits
    • unknown's avatar
      sql_insert.cc: · 3798a7d5
      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.
      3798a7d5
    • unknown's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.0 · 14ab9bef
      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
      14ab9bef
  5. 16 Mar, 2007 7 commits
    • unknown's avatar
      Bug#27006: AFTER UPDATE triggers not fired with INSERT ... ON DUPLICATE KEY · 6d93f150
      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.
      6d93f150
    • unknown's avatar
      Merge gkodinov@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · 43b9ff1b
      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
      43b9ff1b
    • unknown's avatar
      Bug #26261: · 2e8e78a4
      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
      2e8e78a4
    • unknown's avatar
      Merge sgluhov@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · 1a259b88
      unknown authored
      into  mysql.com:/home/gluh/MySQL/Merge/5.0-opt
      
      
      1a259b88
    • unknown's avatar
      Bug#26285 selecting information_schema crahes server · a51b7686
      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
      a51b7686
    • unknown's avatar
      Merge bk@192.168.21.1:mysql-5.0-opt · 6b428e85
      unknown authored
      into  mysql.com:/home/hf/work/mrg/mysql-5.0-opt
      
      
      6b428e85
    • unknown's avatar
      Merge bk@192.168.21.1:mysql-5.0 · 173dc70d
      unknown authored
      into  mysql.com:/home/hf/work/mrg/mysql-5.0-opt
      
      
      sql/sql_parse.cc:
        Auto merged
      173dc70d
  6. 15 Mar, 2007 6 commits
    • unknown's avatar
      Raise version number after cloning 5.0.38 · 0d31e0f3
      unknown authored
      0d31e0f3
    • unknown's avatar
      Merge mysql.com:/home/svoj/devel/bk/mysql-4.1-engines · 19ab799d
      unknown authored
      into  mysql.com:/home/svoj/devel/bk/mysql-5.0-engines
      
      
      19ab799d
    • unknown's avatar
      Merge epotemkin@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · c6ab94bd
      unknown authored
      into  moonbone.local:/mnt/gentoo64/work/27033-bug-5.0-opt-mysql
      
      
      c6ab94bd
    • unknown's avatar
      Bug#27033: 0 as LAST_INSERT_ID() after INSERT .. ON DUPLICATE if rows were · 542f18a3
      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.
      542f18a3
    • unknown's avatar
      Merge mysql.com:/home/hf/work/26833/my50-26833 · 34c55867
      unknown authored
      into  mysql.com:/home/hf/work/mrg/mysql-5.0-opt
      
      
      sql/sql_parse.cc:
        Auto merged
      34c55867
    • unknown's avatar
      Merge bk@192.168.21.1:mysql-5.0 · b6515184
      unknown authored
      into  mysql.com:/home/hf/work/mrg/mysql-5.0-opt
      
      
      mysql-test/r/gis-rtree.result:
        Auto merged
      b6515184