An error occurred fetching the project authors.
  1. 18 May, 2009 1 commit
    • Gleb Shchepa's avatar
      Bug#40825: Error 1356 while selecting from a view · a7294532
      Gleb Shchepa authored
                 with a "HAVING" clause though query works
      
      SELECT from views defined like:
      
        CREATE VIEW v1 (view_column)
          AS SELECT c AS alias FROM t1 HAVING alias
      
      fails with an error 1356:
        View '...' references invalid table(s) or column(s)
        or function(s) or definer/invoker of view lack rights
        to use them
      
      
      CREATE VIEW form with a (column list) substitutes
      SELECT column names/aliases with names from a
      view column list.
      However, alias references in HAVING clause was
      not substituted.
      
      
      The Item_ref::print function has been modified
      to write correct aliased names of underlying
      items into VIEW definition generation/.frm file.
      
      
      mysql-test/r/view.result:
        Added test file for bug #40825.
      mysql-test/t/view.test:
        Added test file for bug #40825.
      sql/item.cc:
        Bug#40825: Error 1356 while selecting from a view
                   with a "HAVING" clause though query works
        
        The Item_ref::print function has been modified
        to write correct aliased names of underlying
        items into VIEW definition generation/.frm file.
      a7294532
  2. 03 Mar, 2009 1 commit
  3. 28 Nov, 2008 1 commit
    • Gleb Shchepa's avatar
      Bug #33461: SELECT ... FROM <view> USE INDEX (...) throws · 41ccbefc
      Gleb Shchepa authored
                  an error
      
      Even after the fix for bug 28701 visible behaviors of
      SELECT FROM a view and SELECT FROM a regular table are
      little bit different:
      
      1. "SELECT FROM regular table USE/FORCE/IGNORE(non
         existent index)" fails with a "ERROR 1176 (HY000):
         Key '...' doesn't exist in table '...'"
      
      2. "SELECT FROM view USING/FORCE/IGNORE(any index)" fails
         with a "ERROR 1221 (HY000): Incorrect usage of
         USE/IGNORE INDEX and VIEW".  OTOH "SHOW INDEX FROM
         view" always returns empty result set, so from the point
         of same behaviour view we trying to use/ignore non
         existent index.
      
      To harmonize the behaviour of USE/FORCE/IGNORE(index)
      clauses in SELECT from a view and from a regular table the
      "ERROR 1221 (HY000): Incorrect usage of USE/IGNORE INDEX
      and VIEW" message has been replaced with the "ERROR 1176
      (HY000): Key '...' doesn't exist in table '...'" message
      like for tables and non existent keys.
      
      
      mysql-test/r/view.result:
        Added test case for bug #33461.
        Updated test case for bug 28701.
      mysql-test/t/view.test:
        Added test case for bug #33461.
        Updated test case for bug 28701.
      sql/sql_view.cc:
        Bug #33461: SELECT ... FROM <view> USE INDEX (...) throws
                    an error
        
        To harmonize the behaviour of USE/FORCE/IGNORE(index)
        clauses in SELECT from a view and from a regular table the
        "ERROR 1221 (HY000): Incorrect usage of USE/IGNORE INDEX
        and VIEW" message has been replaced with the "ERROR 1176
        (HY000): Key '...' doesn't exist in table '...'" message
        like for tables and non existent keys.
      41ccbefc
  4. 27 Oct, 2008 1 commit
    • Sergey Glukhov's avatar
      Bug#39040 valgrind errors/crash when creating views with binlog logging enabled · 380f1a84
      Sergey Glukhov authored
      A string buffers which were included in the 'view' data structure
      were allocated on the stack, causing an invalid pointer when used
      after the function returned.
      The fix: use copy of values for view->md5 & view->queries
      
      
      mysql-test/r/view.result:
        test result
      mysql-test/t/view.test:
        test case
      sql/sql_view.cc:
        A string buffers which were included in the 'view' data structure
        were allocated on the stack, causing an invalid pointer when used
        after the function returned.
        The fix: use copy of values for view->md5 & view->queries
      380f1a84
  5. 26 Mar, 2008 1 commit
    • unknown's avatar
      Fixed bug #35193. · 0b8342ba
      unknown authored
      View definition as SELECT ... FROM DUAL WHERE ... has
      valid syntax, but use of such view in SELECT or
      SHOW CREATE VIEW syntax causes unexpected syntax error.
      
      Server omits FROM DUAL clause when storing view body
      string in a .frm file for further evaluation.
      However, syntax of SELECT-witout-FROM query is more
      restrictive than SELECT FROM DUAL syntax, and doesn't
      allow the WHERE clause.
      
      NOTE: this syntax difference is not documented.
      
      
      View registration procedure has been modified to
      preserve original structure of view's body.
      
      
      
      mysql-test/r/view.result:
        Added test case for bug #35193.
      mysql-test/t/view.test:
        Added test case for bug #35193.
      sql/sql_select.cc:
        Fixed bug #35193.
        The st_select_lex::print function always omits FROM DUAL clause,
        even if original SELECT query has the WHERE clause.
        
        The mysql_register_view function uses this function to reconstruct
        a body of view's AS clause for further evaluation and stores that
        reconstructed clause in a .frm file.
        
        SELECT without FROM syntax is more restrictive than 
        SELECT FROM DUAL syntax: second one allows
        the WHERE clause, but first one is not.
        
        Use of this view in SELECT or SHOW CREATE VIEW queries
        causes unexpected syntax errors.
        
        
        The st_select_lex::print function has been modified to
        reconstruct FROM DUAL clause in queries when needed.
        
        
        TODO: Syntax difference is not documented and should be
        eliminated, however improvement of
        the SELECT-without-FROM syntax is not trivial and leads to
        significant modification of grammar file because of additional
        shift/reduce conflicts.
      0b8342ba
  6. 22 Feb, 2008 1 commit
    • unknown's avatar
      Fix for bug #33049: Assert while running test-as3ap test(mysql-bench · 012aab7d
      unknown authored
                          suite)
      
      Under some circumstances a combination of aggregate functions and
      GROUP BY in a SELECT query over a VIEW could lead to incorrect
      calculation of the result type of the aggregate function. This in
      turn could result in incorrect results, or assertion failures on debug
      builds.
      
      Fixed by changing the logic in Item_sum_hybrid::fix_fields() so that
      the argument's item is dereferenced before calling its type() method.
      
      
      mysql-test/r/view.result:
        Added a test case for bug #33049.
      mysql-test/t/view.test:
        Added a test case for bug #33049.
      sql/item_sum.cc:
        When calculating the result type of an aggregate function, dereference
        the argument's item before calling its type() method.
      012aab7d
  7. 21 Feb, 2008 1 commit
    • unknown's avatar
      Fix for Bug#34337: Server crash when Altering a view using · fa08b280
      unknown authored
      a table name.
        
      The problem was that fill_defined_view_parts() did not return
      an error if a table is going to be altered. That happened if
      the table was already in the table cache. In that case,
      open_table() returned non-NULL value (valid TABLE-instance from
      the cache).
        
      The fix is to ensure that an error is thrown even if the table
      is in the cache.
      
      (This is a backport of the original patch for 5.1)
      
      
      mysql-test/r/view.result:
        Fix result file.
      mysql-test/r/view_grant.result:
        Fix result file.
      mysql-test/t/view.test:
        Add a test case for Bug#34337: Server crash when Altering a view
        using a table name.
      mysql-test/t/view_grant.test:
        Fix order-dependency.
      sql/sql_view.cc:
        Report an error if we're going to work with a table.
      fa08b280
  8. 12 Feb, 2008 1 commit
    • unknown's avatar
      Fix for bug #33389: Selecting from a view into a table from within SP · d5092fa9
      unknown authored
                          or trigger crashes server
      
      Under some circumstances a combination of VIEWs, subselects with outer
      references and PS/SP/triggers could lead to use of uninitialized memory
      and server crash as a result.
      
      Fixed by changing the code in Item_field::fix_fields() so that in cases
      when the field is a VIEW reference, we first check whether the field
      is also an outer reference, and mark it appropriately before returning.
      
      
      mysql-test/r/view.result:
        Added a test case for bug #33389.
      mysql-test/t/view.test:
        Added a test case for bug #33389.
      sql/item.cc:
        In cases when in Item_field::fix_fields() from_field is a view reference,
        do not return too early, i.e. before marking the reference as an outer
        one when needed.
      d5092fa9
  9. 11 Jan, 2008 1 commit
    • unknown's avatar
      Bug#29477: Not all fields of the target table were checked to have a default · 72ebb0aa
      unknown authored
      value when inserting into a view.
      
      The mysql_prepare_insert function checks all fields of the target table that
      directly or indirectly (through a view) are specified in the INSERT
      statement to have a default value. This check can be skipped if the INSERT
      statement doesn't mention any insert fields. In case of a view this allows
      fields that aren't mentioned in the view to bypass the check.
      
      Now fields of the target table are always checked to have a default value
      when insert goes into a view.
      
      
      mysql-test/t/view.test:
        Added a test case for the bug#29477: Not all fields of the target table were 
        checked to have a default value when inserting into a view.
      mysql-test/r/view.result:
        Added a test case for the bug#29477: Not all fields of the target table were 
        checked to have a default value when inserting into a view.
      sql/sql_insert.cc:
        Bug#29477: Not all fields of the target table were checked to have a default
        value when inserting into a view.
        Now fields of the target table are always checked to have a default value
        when insert goes into a view.
      72ebb0aa
  10. 10 Oct, 2007 1 commit
  11. 24 Sep, 2007 1 commit
    • unknown's avatar
      Bug #28702: VIEWs defined with USE/FORCE KEY ignore that request · ca448acc
      unknown authored
      When storing the VIEW the CREATE VIEW command is reconstructed 
      from the parse tree. While constructing the command string
      the index hints specified should also be printed.
      Fixed by adding code to print the index hints when printing a 
      table in the FROM clause.
      
      
      mysql-test/r/view.result:
        Bug #28702: test case
      mysql-test/t/view.test:
        Bug #28702: test case
      sql/sql_select.cc:
        Bug #28702: preserve index hints in a VIEW definition.
      sql/table.h:
        Bug #28702: preserve index hints in a VIEW definition.
      ca448acc
  12. 28 Jul, 2007 1 commit
    • unknown's avatar
      Bug#30020: Insufficient check led to a wrong info provided by the · aa4a3c9a
      unknown authored
      information schema table.
      
      The get_schema_views_record() function fills records in the view table of
      the informations schema with data about given views. Among other info
      the is_updatable flag is set. But the check whether the view is updatable or
      not wasn't covering all cases thus sometimes providing wrong info.
      This might led to a user confusion.
      
      Now the get_schema_views_record function additionally calls to the 
      view->can_be_merge() function to find out whether the view can be updated or
      not.
      
      
      mysql-test/t/view.test:
        Added a test case for the bug#30020: Insufficient check led to a wrong info
        provided by the information schema table.
      mysql-test/r/view.result:
        Added a test case for the bug#30020: Insufficient check led to a wrong info
        provided by the information schema table.
      sql/sql_show.cc:
        Bug#30020: Insufficient check led to a wrong info provided by the
        information schema table.
        Now the get_schema_views_record function additionally calls to the 
        view->can_be_merge() function to find out whether the view can be updated or
        not.
      aa4a3c9a
  13. 05 Jul, 2007 1 commit
    • unknown's avatar
      Fixed bug #29392. · 5d88b654
      unknown authored
      This bug may manifest itself for select queries over a multi-table view
      that includes an ORDER BY clause in its definition. If the select list of 
      the query contains references to the same view column with different
      aliases the names of the columns in the result output will be nevertheless
      the same, coinciding with one of the alias.
      
      The bug happened because the method Item_ref::get_tmp_table_item that
      was inherited by the class Item_direct_view_ref ignored the fact that
      the name of the view column reference must be inherited by the fields
      of the temporary table that was created in order to get the result rows
      sorted.
      
      
      mysql-test/r/view.result:
        Added a test case for bug #29392.
      mysql-test/t/view.test:
        Added a test case for bug #29392.
      sql/item.h:
        Fixed bug #29392.
        This bug may manifest itself for select queries over a multi-table view
        that includes an ORDER BY clause in its definition. If the select list of 
        the query contains references to the same view column with different
        aliases the names of the columns in the result output will be nevertheless
        the same, coinciding with one of the alias.
        
        The bug happened because the method Item_ref::get_tmp_table_item that
        was inherited by the class Item_direct_view_ref ignored the fact that
        the name of the view column reference must be inherited by the fields
        of the temporary table that was created in order to get the result rows
        sorted.
        
        Fixed by providing a proper implementation of the get_tmp_table_item 
        method for the Item_direct_view_ref class.
      5d88b654
  14. 20 Jun, 2007 1 commit
    • unknown's avatar
      Fixed bug #29104: assertion abort for grouping queries using views. · 39bf2b96
      unknown authored
      The abort happened when a query contained a conjunctive predicate
      of the form 'view column = constant' in the WHERE condition and 
      the grouping list also contained a reference to a view column yet
      a different one.
      
      Removed the failing assertion as invalid in a general case.
      
      Also fixed a bug that prevented applying some optimization for grouping
      queries using views. If the WHERE condition of such a query contains
      a conjunctive condition of the form 'view column = constant' and
      this view column is used in the grouping list then grouping by this
      column can be eliminated. The bug blocked performing this elimination.
      
      
      mysql-test/r/view.result:
        Added a test case for bug #29104.
      mysql-test/t/view.test:
        Added a test case for bug #29104.
      sql/item.cc:
        Fixed bug #29104: assertion abort for grouping queries using views.
        The abort happened when a query contained a conjunctive predicate
        of the form 'view column = constant' in the WHERE condition and 
        the grouping list also contained a reference to a view column yet
        a different one.
        
        Removed the failing assertion as invalid in a general case.
        
        Also fixed a bug that prevented applying some optimization for grouping
        queries using views. If the WHERE condition of such a query contains
        a conjunctive condition of the form 'view column = constant' and
        this view column is used in the grouping list then grouping by this
        column can be eliminated. The bug blocked performing this elimination.
        This bug was in the function Item_field::eq while the failing
        assertion was in the function Item_direct_view_ref::eq.
      39bf2b96
  15. 09 Jun, 2007 1 commit
    • unknown's avatar
      Bug#28266 IS_UPDATABLE field on VIEWS table in I_S database is wrong · ce4e9f75
      unknown authored
      IS_UPDATABLE flag is set to 'yes' when the view has at least one updatable column and
      the algorithm is not 'temporary'.
      
      
      mysql-test/r/information_schema.result:
        test result
      mysql-test/r/view.result:
        test result
      mysql-test/t/information_schema.test:
        test case
      mysql-test/t/view.test:
        test case
      sql/sql_show.cc:
        IS_UPDATABLE flag is set to 'yes' when the view has at least one updatable column and
        the algorithm is not 'temporary'.
      ce4e9f75
  16. 06 Jun, 2007 1 commit
    • unknown's avatar
      Bug #28701: · 05390731
      unknown authored
      Views don't have indexes. So they can't take index hints.
      Added a check and disabled the usage of hints for views.
      
      
      mysql-test/r/view.result:
        Bug #28701: test case
      mysql-test/t/view.test:
        Bug #28701: test case
      sql/sql_view.cc:
        Bug #28701: disable usage of hints for views
      05390731
  17. 31 May, 2007 1 commit
    • unknown's avatar
      Fixed bug #27827. · e2c7a5b0
      unknown authored
      ON conditions from JOIN expression were ignored at CHECK OPTION
      check when updating a multi-table view with CHECK OPTION.
      
      The st_table_list::prep_check_option function has been
      modified to to take into account ON conditions at CHECK OPTION check
      It was also changed to build the check option condition only once
      for any update used in PS/SP.
      
      
      sql/table.h:
        Fixed bug #27827.
        The st_table_list::check_option_processed variable has been added
        to build the check option condition only once for any update used
        in PS/SP.
      sql/table.cc:
        Fixed bug #27827.
        The st_table_list::prep_check_option function has been
        modified to to take into account ON conditions at CHECK OPTION check
        It was also changed to build the check option condition only once
        for any update used in PS/SP.
      mysql-test/t/view.test:
        Updated test case for bug #27827.
      mysql-test/r/view.result:
        Updated test case for bug #27827.
      e2c7a5b0
  18. 30 May, 2007 1 commit
    • unknown's avatar
      Fixed bug #28716. · 94507ee7
      unknown authored
      The result of the CHECK OPTION condition evaluation over an
      updated record and records of merged tables was arbitrary and
      dependant on the order of records in the merged tables during
      the execution of SELECT statement.
      
      The CHECK OPTION expression was evaluated over expired record
      buffers (with arbitrary data in the fields).
      
      Rowids of tables used in the CHECK OPTION expression were
      added to temporary table rows. The multi_update::do_updates()
      method was modified to restore necessary record buffers
      before evaluation of the CHECK OPTION condition.
      
      
      sql/sql_class.h:
        Fixed bug #29716.
        The multi_update::unupdatable_check_opt_tables variable
        has been added.
      sql/sql_update.cc:
        Fixed bug #29716.
        Rowids of tables used in the CHECK OPTION expression were
        added to temporary table rows. The multi_update::do_updates()
        method was modified to restore necessary record buffers
        before evaluation of the CHECK OPTION condition.
      mysql-test/t/view.test:
        Updated test case for bug #28716.
      mysql-test/r/view.result:
        Updated test case for bug #28716.
      94507ee7
  19. 24 May, 2007 1 commit
    • unknown's avatar
      Fixed bug #28561: assertion abort for update on multi-table view with · 48af05a8
      unknown authored
      CHECK OPTION and a subquery in WHERE condition.
      The abort was triggered by setting the value of join->tables for
      subqueries in the function JOIN::cleanup. This function was called
      after an invocation of the JOIN::join_free method for subqueries
      used in WHERE condition.
      
      
      mysql-test/r/view.result:
        Added a test case for bug #28561.
      mysql-test/t/view.test:
        Added a test case for bug #28561.
      sql/sql_select.cc:
        Fixed bug #28561: assertion abort for update on multi-table view with
        CHECK OPTION and a subquery in WHERE condition.
        The abort was triggered by setting the value of join->tables for
        subqueries in the function JOIN::cleanup. This function was called
        after an invocation of the JOIN::join_free method for subqueries
        used in WHERE condition.
        Setting the value of join->tables to for a subquery created serious
        problems for checking WHERE condition after update of the multi-table
        view as this check is performed in the do_select function right
        after a call of the JOIN::join_free method.
        In fact setting join->tables to 0 in JOIN::cleanup is not needed 
        anywhere in the current code.
      48af05a8
  20. 09 May, 2007 1 commit
    • unknown's avatar
      Bug #27921 View ignores precision for CAST() · f2a52dd0
      unknown authored
      Item_decimal_typecast::print properly implemented
      
      
      mysql-test/r/view.result:
        Bug #27921 View ignores precision for CAST()
        test result
      mysql-test/t/view.test:
        Bug #27921 View ignores precision for CAST()
        test case
      sql/field.cc:
        zero decimals handling unified
      sql/item_create.cc:
        Bug #27921 View ignores precision for CAST()
        create_func_cast parameters changed, zero precision handling unified
      sql/item_create.h:
        Bug #27921 View ignores precision for CAST()
        create_func_cast parameters changed
      sql/item_func.cc:
        Bug #27921 View ignores precision for CAST() 
        Item_decimal_typecast::print properly implemented
      sql/item_func.h:
        Bug #27921 View ignores precision for CAST()
        max_length counting fixed
      sql/my_decimal.h:
        Bug #27921 View ignores precision for CAST()
        my_decimal_trim() implemented to unify zero precision handling
      sql/sql_yacc.yy:
        Bug #27921 View ignores precision for CAST()
        create_func_cast calls simplified
      f2a52dd0
  21. 20 Apr, 2007 1 commit
    • unknown's avatar
      Bug #27786: · e0444ba4
      unknown authored
      When merging views into the enclosing statement
      the ORDER BY clause of the view is merged to the
      parent's ORDER BY clause.
      However when the VIEW is merged into an UNION
      branch the ORDER BY should be ignored. 
      Use of ORDER BY for individual SELECT statements
      implies nothing about the order in which the rows
      appear in the final result because UNION by default
      produces unordered set of rows.
      Fixed by ignoring the ORDER BY clause from the merge
      view when expanded in an UNION branch.
      
      
      mysql-test/r/view.result:
        Bug #27786: test case
      mysql-test/t/view.test:
        Bug #27786: test case
      sql/sql_lex.h:
        Bug #27786: add a is_union() inlined function
        Returns true if the unit represents an UNION.
      sql/sql_view.cc:
        Bug #27786: ignore ORDER BY in mergeable views when in UNION context
      e0444ba4
  22. 12 Apr, 2007 1 commit
    • unknown's avatar
      Bug#5507: TRUNCATE does not work with views. · 0b54001b
      unknown authored
      Support of views wasn't implemented for the TRUNCATE statement.
      Now TRUNCATE on views has the same semantics as DELETE FROM view:
      mysql_truncate() checks whether the table is a view and falls back
      to delete if so.
      In order to initialize properly the LEX::updatable for a view
      st_lex::can_use_merged() now allows usage of merged views for the
      TRUNCATE statement.
      
      
      mysql-test/r/truncate.result:
        Added a test case for the Bug#5507: TRUNCATE does not work with views.
      mysql-test/t/truncate.test:
        Added a test case for the Bug#5507: TRUNCATE does not work with views.
      sql/sql_lex.cc:
        Bug#5507: TRUNCATE does not work with views.
        can_use_merged() was denying of usage of merged views for a
        TRUNCATE statement. This results in improper initialization
        of view LEX::updatable. Fixed.
      sql/sql_delete.cc:
        Bug#5507: TRUNCATE does not work with views.
        1.mysql_truncate() was lacking of check whether the table is view. Added.
        2.mysql_truncate() calls mysql_delete(), but mysql_delete() always reports
        errors as "DELETE" errors. Fixed.
      mysql-test/t/view.test:
        Updated test case for Bug#14540: OPTIMIZE, ANALYZE, REPAIR applied 
        to not a view.
      mysql-test/r/view.result:
        Updated test case for Bug#14540: OPTIMIZE, ANALYZE, REPAIR applied 
        to not a view.
      0b54001b
  23. 05 Mar, 2007 1 commit
    • unknown's avatar
      Fixed bug #26560. · 6da758c2
      unknown authored
      The flag alias_name_used was not set on for the outer references
      in subqueries. It resulted in replacement of any outer reference
      resolved against an alias for a full field name when the frm 
      representation of a view with a subquery was generated. 
      If the subquery and the outer query referenced the same table in
      their from lists this replacement effectively changed the meaning
      of the view and led to wrong results for selects from this view. 
      
      Modified several functions to ensure setting the right value of
      the alias_name_used flag for outer references resolved against
      aliases.
       
      
      
      mysql-test/r/view.result:
        Added a test case for bug #26560.
      mysql-test/t/view.test:
        Added a test case for bug #26560.
      sql/item.cc:
        Fixed bug #26560.
        Made the function resolve_ref_in_select_and_group analyze the return
        value of the last parameter with the type of the name resolution for
        the submitted reference. If the reference has been resolved against 
        an alias name from select list then its flag alias_name_used is set on.
        Now this value is used in Item_field::fix_outer_field to initialize the flag
        when the item_ref object is created for an outer reference.
        Added a parameter for the second Item_ref::Item_ref constructor to initialize
        properly the flag alias_name_used. The default value of the parameter is FALSE.
        If this flag is set on at the creation of an object by this constructor it
        will never be changed. Corrected appropriately the Item_ref::set_properties
        function.
        The function Item_ref::print now prints alias name for an outer reference
        if the flag alias_name_used is set on.
      sql/item.h:
        Fixed bug #26560.
        Added a parameter for the second Item_ref::Item_ref constructor to initialize
        properly the flag alias_name_used. The default value of the parameter is FALSE.
        A similar change has been applied to the first Item_direct_ref::Item_direct_ref
        constructor.
      sql/mysql_priv.h:
        Fixed bug #26560.
        Added an an enumeration type enum_resolution_type to return info on
        how the function find_item_in_list has resolved the submitted item.
        The type is used only for this function.
      sql/sql_base.cc:
        Fixed bug #26560.
        Made the last parameter of the function find_field_in_tables return
        more detailed information on how the submitted item has been resolved.
        Now it says whether the item has been resolved
          against an alias name,
          or as a field name without alias,
          or as a field name hidden by alias, 
          or was resolved ignoring alias.
      sql/sql_select.cc:
        Fixed bug #26560.
        Took into account the new type of the last parameter of the function
        find_item_in_list.
      6da758c2
  24. 23 Feb, 2007 1 commit
    • unknown's avatar
      Fix test for views with national characters, · 49b66418
      unknown authored
      which accidentally got broken during the merge
      on 16-Feb-2007.
      
      
      mysql-test/r/view.result:
        Updated result file.
      mysql-test/t/view.test:
        Fix test for views with national characters,
        which accidentally got broken during the merge
        on 16-Feb-2007.
        
        Now view.test is in UTF8 character set,
        so SET NAMES is required.
      49b66418
  25. 16 Feb, 2007 1 commit
  26. 12 Feb, 2007 2 commits
    • unknown's avatar
      Bug#24532 (The return data type of IS TRUE is different from similar · a475ed7c
      unknown authored
        operations)
      
      Before this change, the boolean predicates:
      - X IS TRUE,
      - X IS NOT TRUE,
      - X IS FALSE,
      - X IS NOT FALSE
      were implemented by expanding the Item tree in the parser, by using a
      construct like:
      Item_func_if(Item_func_ifnull(X, <value>), <value>, <value>)
      
      Each <value> was a constant integer, either 0 or 1.
      
      A bug in the implementation of the function IF(a, b, c), in
      Item_func_if::fix_length_and_dec(), would cause the following :
      
      When the arguments b and c are both unsigned, the result type of the
      function was signed, instead of unsigned.
      
      When the result of the if function is signed, space for the sign could be
      counted twice (in the max() expression for a signed argument, and in the
      total), causing the member max_length to be too high.
      
      An effect of this is that the final type of IF(x, int(1), int(1)) would be
      int(2) instead of int(1).
      
      With this fix, the problems found in Item_func_if::fix_length_and_dec()
      have been fixed.
      
      While it's semantically correct to represent 'X IS TRUE' with
      Item_func_if(Item_func_ifnull(X, <value>), <value>, <value>),
      there are however more problems with this construct.
      
      a)
      Building the parse tree involves :
      - creating 5 Item instances (3 ints, 1 ifnull, 1 if),
      - creating each Item calls my_pthread_getspecific_ptr() once in the operator
        new(size), and a second time in the Item::Item() constructor, resulting
        in a total of 10 calls to get the current thread.
      Evaluating the expression involves evaluating up to 4 nodes at runtime.
      This representation could be greatly simplified and improved.
      
      b)
      Transforming the parse tree internally with if(ifnull(...)) is fine as long
      as this transformation is internal to the server implementation.
      With views however, the result of the parse tree is later exposed by the
      ::print() functions, and stored as part of the view definition.
      Doing this has long term consequences:
      
      1)
      The original semantic 'X IS TRUE' is lost, and replaced by the
      if(ifnull(...)) expression. As a result, SHOW CREATE VIEW does not restore
      the original code.
      
      2)
      Should a future version of MySQL implement the SQL BOOLEAN data type for
      example, views created today using 'X IS NULL' can be exported using
      mysqldump, and imported again. Such views would be converted correctly and
      automatically to use a BOOLEAN column in the future version.
      With 'X IS TRUE' and the current implementations, views using these
      "boolean" predicates would not be converted during the export/import, and
      would use integer columns instead.
      The difference traces back to how SHOW CREATE VIEW preserves 'X IS NULL' but
      does not preserve the 'X IS TRUE' semantic.
      
      With this fix, internal representation of 'X IS TRUE' booleans predicates
      has changed, so that:
      - dedicated Item classes are created for each predicate,
      - only 1 Item is created to represent 1 predicate
      - my_pthread_getspecific_ptr() is invoked 1 time instead of 10
      - SHOW CREATE VIEW preserves the original semantic, and prints 'X IS TRUE'.
      
      Note that, because of the fix in Item_func_if, views created before this fix
      will:
      - correctly use a int(1) type instead of int(2) for boolean predicates,
      - incorrectly print the if(ifnull(...), ...) expression in SHOW CREATE VIEW,
      since the original semantic (X IS TRUE) has been lost.
      - except for the syntax used in SHOW CREATE VIEW, these views will operate
      properly, no action is needed.
      
      Views created after this fix will operate correctly, and will preserve the
      original code semantic in SHOW CREATE VIEW.
      
      
      mysql-test/r/func_if.result:
        IF(x, unsigned, unsigned) should be unsigned.
      mysql-test/r/view.result:
        Preserve the semantic of 'X IS [NOT] (TRUE|FALSE)' boolean predicates.
      mysql-test/t/func_if.test:
        IF(x, unsigned, unsigned) should be unsigned.
      mysql-test/t/view.test:
        Preserve the semantic of 'X IS [NOT] (TRUE|FALSE)' boolean predicates.
      sql/item_cmpfunc.cc:
        Preserve the semantic of 'X IS [NOT] (TRUE|FALSE)' boolean predicates.
        IF(x, unsigned, unsigned) should be unsigned.
      sql/item_cmpfunc.h:
        Preserve the semantic of 'X IS [NOT] (TRUE|FALSE)' boolean predicates.
      sql/sql_yacc.yy:
        Preserve the semantic of 'X IS [NOT] (TRUE|FALSE)' boolean predicates.
      a475ed7c
    • unknown's avatar
      Fixed bug #26209. · ac8e0293
      unknown authored
      The function make_unireg_sortorder ignored the fact that any
      view field is represented by a 'ref' object.
      This could lead to wrong results for the queries containing
      both GROUP BY and ORDER BY clauses.
      
      
      mysql-test/r/view.result:
        Added a test case for bug #26209.
      mysql-test/t/view.test:
        Added a test case for bug #26209.
      ac8e0293
  27. 09 Feb, 2007 1 commit
    • unknown's avatar
      Bug#12122: The MERGE algorithm isn't applicable if the ORDER BY clause is · 308da651
      unknown authored
      present.
      
      A view created with CREATE VIEW ... ORDER BY ... cannot be resolved with
      the MERGE algorithm, even when no other part of the CREATE VIEW statement
      would require the view to be resolved using the TEMPTABLE algorithm.
      
      The check for presence of the ORDER BY clause in the underlying select is 
      removed from the st_lex::can_be_merged() function.
      The ORDER BY list of the underlying select is appended to the ORDER BY list 
      
      
      mysql-test/t/view.test:
        Added a test case for bug#12122: Views with ORDER BY can't be resolved using MERGE algorithm.
      mysql-test/r/view.result:
        Added a test case for bug#12122: Views with ORDER BY can't be resolved using MERGE algorithm.
      sql/sql_lex.cc:
        Bug#12122: Views with ORDER BY can't be resolved using MERGE algorithm.
        The st_lex::can_be_merged() function now allows views with the ORDER BY
        clause to be resolved using MERGE algorithm. The ORDER BY list of the view 
        is appended to the ORDER BY list of the embedding select.
      308da651
  28. 07 Feb, 2007 2 commits
    • unknown's avatar
      Fixed bug #25931. · 3609c3a4
      unknown authored
      View check option clauses were ignored for updates of multi-table
      views when the updates could not be performed on fly and the rows
      to update had to be put into temporary tables first.
      
      
      
      mysql-test/r/view.result:
        Added a test case for bug #25931.
      mysql-test/t/view.test:
        Added a test case for bug #25931.
        Adjusted another existed test case to have the correct result.
      sql/sql_update.cc:
        Fixed bug #25931.
        View check option clauses were ignored for updates of multi-table
        views when the updates could not be performed on fly and the rows
        to update had to be put into temporary tables first.
        Added the required check to multi_update::do_updates to fix the problem.
      3609c3a4
    • unknown's avatar
      Fixed bug #26124: SELECT from a view wrapper over a table · 3a54e593
      unknown authored
      with a column of the DATETIME type could return a wrong 
      result set if the WHERE clause included a BETWEEN condition
      on the column.
      Fixed the method Item_func_between::fix_length_and_dec
      where the aggregation type for BETWEEN predicates calculated
      incorrectly if the first argument was a view column of the
      DATETIME type.
      
      
      mysql-test/r/view.result:
        Added a test case for bug #26124.
      mysql-test/t/view.test:
        Added a test case for bug #26124.
      3a54e593
  29. 04 Feb, 2007 1 commit
    • unknown's avatar
      BUG#25897: Some queries are no longer possible after a CREATE VIEW · 86b715a7
      unknown authored
                 fails
      
      The bug was introduced with the push of the fix for bug#20953: after
      the error on view creation we never reset the error state, so some
      valid statements would give the same error after that.
      
      The solution is to properly reset the error state.
      
      
      mysql-test/r/view.result:
        Add result for bug#25897: Some queries are no longer possible after
        a CREATE VIEW fails.
      mysql-test/t/view.test:
        Add test case for bug#25897: Some queries are no longer possible after
        a CREATE VIEW fails.
      sql/sql_lex.cc:
        Add st_parsing_options::reset() method, call it from lex_start().
      sql/sql_lex.h:
        Add st_parsing_options::reset() method, call it from constructor.
      86b715a7
  30. 18 Jan, 2007 1 commit
    • unknown's avatar
      Fixed bug #25580: incorrect stored representations of views in cases · af321686
      unknown authored
      when they contain the '!' operator.
      Added an implementation for the method Item_func_not::print. 
      The method encloses any NOT expression into extra parentheses to avoid
      incorrect stored representations of views that use the '!' operators.
      Without this change when a view was created that contained
      the expression !0*5  its stored representation contained not this
      expression but rather the expression not(0)*5 . 
      The operator '!' is of a higher precedence than '*', while NOT is 
      of a lower precedence than '*'. That's why the expression !0*5 
      is interpreted as not(0)*5, while the expression not(0)*5 is interpreted
      as not((0)*5) unless sql_mode is set to HIGH_NOT_PRECEDENCE.
      Now we translate !0*5 into (not(0))*5. 
      
      
      mysql-test/r/sp-code.result:
        Adjusted results after the fix of bug 25580.
      mysql-test/r/subselect.result:
        Adjusted results after the fix of bug 25580.
      mysql-test/r/view.result:
        Added a test case for bug #25580.
      mysql-test/t/view.test:
        Added a test case for bug #25580.
      sql/item_cmpfunc.cc:
        Fixed bug #25580: incorrect stored representations of views in cases
        when they contain the '!' operator.
        Added an implementation for the method Item_func_not::print. 
        The method encloses the NOT expression into extra parenthesis to avoid
        incorrect stored representations of views that use the '!' operators.
      sql/item_cmpfunc.h:
        Fixed bug #25580: incorrect stored representations of views in cases
        when they contain the '!' operator.
        Added an implementation for the method Item_func_not::print. 
        The method encloses the NOT expression into extra parenthesis to avoid
        incorrect stored representations of views that use the '!' operators.
      af321686
  31. 19 Dec, 2006 1 commit
    • unknown's avatar
      Fix for BUG#24293: '\Z' token is not handled correctly in views. · b66ab7f8
      unknown authored
      If SELECT-part of CREATE VIEW statement contains '\Z',
      it is not handled correctly.
      
      The problem was in String::print().
      Symbol with code 032 (26) is replaced with '\z',
      which is not supported by the lexer.
      
      The fix is to replace the symbol with '\Z'.
      
      
      mysql-test/r/view.result:
        Update result file.
      mysql-test/t/view.test:
        Add test case for BUG#24293.
      sql/sql_string.cc:
        We should replace 032 with \Z, since lexer does not understand \z.
      b66ab7f8
  32. 27 Oct, 2006 1 commit
    • unknown's avatar
      BUG#22584: last_insert_id not updated after inserting a record through · 532735e6
      unknown authored
      a updatable view.
      
      When there's a VIEW on a base table that have AUTO_INCREMENT column, and
      this VIEW doesn't provide an access such column, after INSERT to such
      VIEW LAST_INSERT_ID() did not return the value just generated.
      
      This behaviour is intended and correct, because if the VIEW doesn't list
      some columns then these columns are effectively hidden from the user,
      and so any side effects of inserting default values to them.
      
      However, there was a bug that such statement inserting into a view would
      reset LAST_INSERT_ID() instead of leaving it unchanged.
      
      This patch restores the original value of LAST_INSERT_ID() instead of
      resetting it to zero.
      
      
      mysql-test/r/view.result:
        Add result for bug#22584: last_insert_id not updated after inserting
        a record through a updatable view.
      mysql-test/t/view.test:
        Add test case for bug#22584: last_insert_id not updated after inserting
        a record through a updatable view.
      sql/sql_parse.cc:
        When we have inserted into a view, and AUTO_INCREMENT column is not
        accessed from this view, instead of setting LAST_INSERT_ID to zero set
        it to the value it had before this statement was executed.
      532735e6
  33. 17 Oct, 2006 1 commit
    • unknown's avatar
      Fix previous bad patch for Bug#14262. · 48dfeb4d
      unknown authored
      Remove table engine qualification where it's unnecessary.
      
      
      mysql-test/r/view.result:
        Remove requirement for innodb where not needed.  (Running this test alone
        raised warnings that it was using myisam.)
      mysql-test/t/view.test:
        Remove requirement for innodb where not needed.  (Running this test alone
        raised warnings that it was using myisam.)
      sql/sql_parse.cc:
        Fix previous bad re-patch.
      sql/sql_view.cc:
        Fix previous bad re-patch.
      48dfeb4d
  34. 12 Oct, 2006 1 commit
    • unknown's avatar
      BUG#20953: create proc with a create view that uses local vars/params · 6d1fdc73
      unknown authored
                 should fail to create
      
      The problem was that this type of errors was checked during view
      creation, which doesn't happen when CREATE VIEW is a statement of
      a created stored routine.
      
      The solution is to perform the checks at parse time.  The idea of the
      fix is that the parser checks if a construction just parsed is allowed
      in current circumstances by testing certain flags, and this flags are
      reset for VIEWs.
      
      The side effect of this change is that if the user already have
      such bogus routines, it will now get a error when trying to do
      
        SHOW CREATE PROCEDURE proc;
      
      (and some other) and when trying to execute such routine he will get
      
        ERROR 1457 (HY000): Failed to load routine test.p5. The table mysql.proc is missing, corrupt, or contains bad data (internal code -6)
      
      However there should be very few such users (if any), and they may
      (and should) drop these bogus routines.
      
      
      mysql-test/r/sp-error.result:
        Add result for bug#20953: create proc with a create view that uses
        local vars/params should fail to create.
      mysql-test/r/view.result:
        Update results.
      mysql-test/t/sp-error.test:
        Add test case for bug#20953: create proc with a create view that uses
        local vars/params should fail to create.
      mysql-test/t/view.test:
        Add second test for variable in a view.
        Remove SP variable in a view test, as it tests wrong behaviour.
        Add test for derived table in a view.
      sql/sql_lex.cc:
        Remove LEX::variables_used.
      sql/sql_lex.h:
        Remove LEX::variables_used and add st_parsing_options structure and
        LEX::parsing_options member.
      sql/sql_view.cc:
        Move some error checking to sql/sql_yacc.yy.
      sql/sql_yacc.yy:
        Check for disallowed syntax in a CREATE VIEW at parse time to rise a
        error when it is used inside CREATE PROCEDURE and CREATE FUNCTION, as
        well as by itself.
      6d1fdc73
  35. 10 Oct, 2006 1 commit
    • unknown's avatar
      Bug#19111: TRIGGERs selecting from a VIEW on the firing base table fail. · 469ff92d
      unknown authored
      In a trigger or a function used in a statement it is possible to do
      SELECT from a table being modified by the statement.  However,
      encapsulation of such SELECT into a view and selecting from a view
      instead of direct SELECT was not possible.
      
      This happened because tables used by views (which in their turn
      were used from functions/triggers) were not excluded from checks
      in unique_table() routine as it happens for the rest of tables
      added to the statement table list for prelocking.
      
      With this fix we ignore all such tables in unique_table(), thus
      providing consistency: inside a trigger or a functions SELECT from
      a view may be used where plain SELECT is allowed.  Modification of
      the same table from function or trigger is still disallowed.  Also,
      this patch doesn't affect the case where SELECT from the table being
      modified is done outside of function of trigger, such SELECTs are
      still disallowed (this limitation and visibility problem when function
      select from a table being modified are subjects of bug 21326).  See
      also bug 22427.
      
      
      mysql-test/r/view.result:
        Add result for bug#19111: TRIGGERs selecting from a VIEW on the
        firing base table fail.
      mysql-test/t/view.test:
        Add test case for bug#19111: TRIGGERs selecting from a VIEW on the
        firing base table fail.
      sql/sql_base.cc:
        In unique_table() do not check tables that are used in a stored
        function or a trigger ('prelocking_placeholder' is set).  If such
        function or a trigger will attempt to modify a table, the error will
        be given, however select is allowed there.
      469ff92d
  36. 29 Sep, 2006 1 commit
    • unknown's avatar
      bug #16813 (WITH CHECK OPTION fails with UPDATE) · 5389cc16
      unknown authored
      We use the condition from CHECK OPTION twice handling UPDATE command.
      First we construnct 'update_cond' AND 'option_cond'
      condition to select records to be updated, then we check the
      'option_cond' for the updated row.
      The problem is that first 'AND' condition is optimized during the 'select'
      which can break 'option_cond' structure, so it will be unusable for
      the sectond use - to check the updated row.
      Possible soultion is either use copy of the condition in the first
      use or to make optimization less traumatic for the operands.
      I picked the first one. 
      
      
      mysql-test/r/view.result:
        result fixed
      mysql-test/t/view.test:
        testcase
      sql/table.cc:
        now we use the copy of the CHECK OPTION condition to construct
        the select's condition
      5389cc16
  37. 28 Sep, 2006 2 commits
    • unknown's avatar
      view.test: · 04bf9cc7
      unknown authored
        After merge fix
      
      
      mysql-test/t/view.test:
        After merge fix
      04bf9cc7
    • unknown's avatar
      Fixed bug#5505: Wrong error message on INSERT into a view · d332c37c
      unknown authored
      On an INSERT into an updatable but non-insertable view an error message was
      issued stating the view being not updatable. This can lead to a confusion of a
      user.
      
      A new error message is introduced. Is is showed when a user tries to insert
      into a non-insertable view.
      
      
      sql/sql_base.cc:
        Fixed bug#5505: Wrong error message on INSERT into a view
        The update_non_unique_table_error() function now issues proper
        error for an INSERT.
      sql/sql_insert.cc:
        Fixed bug#5505: Wrong error message on INSERT into a view
        Issue the ER_NON_INSERTABLE_TABLE error instead of the 
        ER_NON_UPDATABLE_TABLE on insert into a view.
      sql/sql_view.cc:
        Fixed bug#5505: Wrong error message on INSERT into a view
        Issue the ER_NON_INSERTABLE_TABLE error instead of the
        ER_NON_UPDATABLE_TABLE on insert into a view.
      mysql-test/r/view.result:
        Added the test case for bug#5505: Wrong error message on INSERT into a view
        Corrected a few test cases after fixing bug#5505
      mysql-test/t/view.test:
        Added the test case for bug#5505: Wrong error message on INSERT into a view
        Corrected a few test cases after fixing bug#5505
      sql/share/errmsg.txt:
        Fixed bug#5505: Wrong error message on INSERT into a view
        Added the ER_NON_INSERTABLE_TABLE error definition.
      d332c37c