An error occurred fetching the project authors.
  1. 14 Oct, 2008 1 commit
    • Davi Arnaut's avatar
      Bug#38823: Invalid memory access when a SP statement does wildcard expansion · 017307f2
      Davi Arnaut authored
      The problem is that field names constructed due to wild-card
      expansion done inside a stored procedure could point to freed
      memory if the expansion was performed after the first call to
      the stored procedure.
      
      The problem was solved by patch for Bug#38691. The solution
      was to allocate the database, table and field names in the
      in the statement memory instead of table memory.
      
      mysql-test/r/sp.result:
        Add test case result for Bug#38823
      mysql-test/t/sp.test:
        Add test case for Bug#38823
      sql/item.cc:
        Remark that this also impacts wildcard expansion inside SPs.
      017307f2
  2. 20 Sep, 2008 1 commit
    • Kristofer Pettersson's avatar
      Bug#38469 invalid memory read and/or crash with utf8 text field, stored procedure, uservar · f0352e34
      Kristofer Pettersson authored
                  
      A stored procedure involving substrings could crash the server on certain
      platforms because of invalid memory reads.
                
      During storing the new blob-field value, the cached value's address range
      overlapped that of the new field value. This caused problems when the 
      cached value storage was reallocated to provide access for a new 
      characater set representation. The patch checks the address ranges, and if
      they overlap, the new field value is copied to a new storage before it is
      converted to the new character set.
      
      
      mysql-test/r/sp.result:
        Added result set
      mysql-test/t/sp.test:
        Added test case
      sql/field.cc:
        The source and destination address ranges of a character conversion must not overlap or the 'from' address will be invalidated as the temporary value-
        object is re-allocated to fit the new character set.
      sql/field.h:
        Added comments
      f0352e34
  3. 20 Aug, 2008 1 commit
    • Sergey Glukhov's avatar
      Bug#38291 memory corruption and server crash with view/sp/function · de73b729
      Sergey Glukhov authored
      Send_field.org_col_name has broken value on secondary execution.
      It happens when result field is created from the field which belongs to view
      due to forgotten assignment of some Send_field attributes. 
      The fix:
      set Send_field.org_col_name,org_table_name with correct value during Send_field intialization.
      
      mysql-test/r/metadata.result:
        result fix
        The result file was changed because now forgotten attributes are properly set.
      mysql-test/r/sp.result:
        test result
      mysql-test/t/sp.test:
        test case
      sql/item.cc:
        Send_field.org_col_name has broken value on secondary execution.
        It happens when result field is created from the field which belongs to view
        due to forgotten assignment of some Send_field attributes. 
        The fix:
        set Send_field.org_col_name,org_table_name with correct value during Send_field intialization.
      tests/mysql_client_test.c:
        test case fix
        The test was changed because now forgotten attributes are properly set.
      de73b729
  4. 31 Jan, 2008 1 commit
    • unknown's avatar
      Bug#30787: Stored function ignores user defined alias. · 754c3f51
      unknown authored
      Simple subselects are pulled into upper selects. This operation substitutes the
      pulled subselect for the first item from the select list of the subselect.
      If an alias is defined for a subselect it is inherited by the replacement item.
      As this is done after fix_fields phase this alias isn't showed if the
      replacement item is a stored function. This happens because the Item_func_sp::make_field
      function makes send field from its result_field and ignores the defined alias.
      
      Now when an alias is defined the Item_func_sp::make_field function sets it for
      the returned field.
      
      
      mysql-test/t/sp.test:
        Added a test case for the bug#30787: Stored function ignores user defined alias.
      mysql-test/r/sp.result:
        Added a test case for the bug#30787: Stored function ignores user defined alias.
      sql/item_func.cc:
        Bug#30787: Stored function ignores user defined alias.
        Now when an alias is defined the Item_func_sp::make_field function sets it for
        the returned field.
      754c3f51
  5. 23 Jan, 2008 2 commits
    • unknown's avatar
      manual merge · 8430df5a
      unknown authored
      8430df5a
    • unknown's avatar
      Bug#33618 (Crash in sp_rcontext) · e6a077e3
      unknown authored
      Bug 33983 (Stored Procedures: wrong end <label> syntax is accepted)
      
      The server used to crash when REPEAT or another control instruction
      was used in conjunction with labels and a LEAVE instruction.
      
      The crash was caused by a missing "pop" of handlers or cursors in the
      code representing the stored program. When executing the code in a loop,
      this missing "pop" would result in a stack overflow, corrupting memory.
      
      Code generation has been fixed to produce the missing h_pop/c_pop
      instructions.
      
      Also, the logic checking that labels at the beginning and the end of a
      statement are matched was incorrect, causing Bug 33983.
      End labels, when used, must match the label used at the beginning of a block.
      
      
      mysql-test/r/sp-code.result:
        Bug#33618 (Crash in sp_rcontext)
      mysql-test/r/sp-error.result:
        Bug 33983 (Stored Procedures: wrong end <label> syntax is accepted)
      mysql-test/r/sp.result:
        Bug#33618 (Crash in sp_rcontext)
      mysql-test/t/sp-code.test:
        Bug#33618 (Crash in sp_rcontext)
      mysql-test/t/sp-error.test:
        Bug 33983 (Stored Procedures: wrong end <label> syntax is accepted)
      mysql-test/t/sp.test:
        Bug#33618 (Crash in sp_rcontext)
      sql/sp_head.cc:
        Bug#33618 (Crash in sp_rcontext)
      sql/sp_head.h:
        Bug#33618 (Crash in sp_rcontext)
      sql/sp_rcontext.cc:
        Bug#33618 (Crash in sp_rcontext)
      sql/sp_rcontext.h:
        Bug#33618 (Crash in sp_rcontext)
      sql/sql_yacc.yy:
        Bug#33618 (Crash in sp_rcontext)
      e6a077e3
  6. 08 Jan, 2008 1 commit
  7. 16 Oct, 2007 1 commit
    • unknown's avatar
      Implementing code review comments · 28ef3b2a
      unknown authored
      mysql-test/r/sp.result:
        Added tests for coverage
      mysql-test/t/sp.test:
        Added tests for coverage
      sql/sql_udf.cc:
        Code cleanup
      28ef3b2a
  8. 10 Oct, 2007 1 commit
  9. 04 Oct, 2007 2 commits
    • unknown's avatar
      apply patch for bug#31035 to 5.0.50 release clone · 9e89a087
      unknown authored
      mysql-test/r/sp.result:
        apply patch for bug#31035
      mysql-test/t/sp.test:
        apply patch for bug#31035
      sql/item_func.cc:
        apply patch for bug#31035
      9e89a087
    • unknown's avatar
      Fix for BUG#31035: select from function, group by result crasher. · 4f14c13a
      unknown authored
      This actually, fix for the patch for bug-27354. The problem with
      the patch was that Item_func_sp::used_tables() was updated, but
      Item_func_sp::const_item() was not. So, for Item_func_sp, we had
      the following inconsistency:
        - used_tables() returned RAND_TABLE, which means that the item
          can produce "random" results;
        - but const_item() returned TRUE, which means that the item is
          a constant one.
      
      The fix is to change Item_func_sp::const_item() behaviour: it must
      return TRUE (an item is a constant one) only if a stored function
      is deterministic and each of its arguments (if any) is a constant
      item.
      
      
      mysql-test/r/sp.result:
        Update result file.
      mysql-test/t/sp.test:
        Add test cases for BUG-31035, BUG-31191, BUG-31226
      sql/item_func.cc:
        Make Item::const_item() be consistent with Item::used_tables().
      4f14c13a
  10. 20 Sep, 2007 1 commit
    • unknown's avatar
      Bug#27747 database metadata doesn't return sufficient column default info · fac190a2
      unknown authored
      added get_field_default_value() function which obtains default value from the field
      (used in store_create_info() & get_schema_column_record() functions)
      
      
      mysql-test/r/alter_table.result:
        result fix
      mysql-test/r/create.result:
        result fix
      mysql-test/r/ctype_collate.result:
        result fix
      mysql-test/r/ctype_recoding.result:
        result fix
      mysql-test/r/default.result:
        result fix
      mysql-test/r/gis.result:
        result fix
      mysql-test/r/grant.result:
        result fix
      mysql-test/r/information_schema.result:
        result fix
      mysql-test/r/key.result:
        result fix
      mysql-test/r/mysql.result:
        result fix
      mysql-test/r/ps_1general.result:
        result fix
      mysql-test/r/show_check.result:
        result fix
      mysql-test/r/sp.result:
        result fix
      mysql-test/r/type_enum.result:
        result fix
      mysql-test/r/type_ranges.result:
        result fix
      mysql-test/t/information_schema.test:
        test case
      fac190a2
  11. 03 Sep, 2007 1 commit
    • unknown's avatar
      Bug#29408 Cannot find view in columns table if the selection contains a function · ee0b7d89
      unknown authored
      Use view db name as thread default database, in order to ensure
      that the view is parsed and prepared correctly.
      
      
      mysql-test/r/sp.result:
        test result
      mysql-test/t/sp.test:
        test case
      sql/sql_parse.cc:
        copy thd->db_length to table_list->db_length
      sql/sql_view.cc:
        Use view db name as thread default database, in order to ensure
        that the view is parsed and prepared correctly.
      ee0b7d89
  12. 29 Aug, 2007 1 commit
  13. 03 Aug, 2007 1 commit
  14. 29 Jul, 2007 1 commit
    • unknown's avatar
      Fixed bug #30120. · 33fc4ad4
      unknown authored
      SP with local variables with non-ASCII names crashed the server.
      
      The server replaces SP local variable names with NAME_CONST calls
      when putting statements into the binary log. It used UTF8-encoded
      item names as variable names for the replacement inside NAME_CONST
      calls. However, statement string may be encoded by any
      known character set by the SET NAMES statement.
      The server used byte length of UTF8-encoded names to increment
      the position in the query string that led to array index overrun.
      
      
      sql/item.cc:
        Fixed bug #30120.
        The Item_splocal class constructor has been modified to
        accept new parameter `len_in_q': the byte length of
        variable name in the query string.
      sql/item.h:
        Fixed bug #30120.
        The Item_splocal class has been modified to keep new
        field `len_in_query': the byte length of variable name in
        the query string.
      sql/sp_head.cc:
        Fixed bug #30120.
        The subst_spvars function has been modified to increment
        position in the query string by the lengths of not
        encoded variable names instead of byte length of names
        encoded to UTF-8.
      sql/sql_yacc.yy:
        Fixed bug #30120.
        The simple_ident rule action has been modified to
        pass the byte length of the local variable name token
        to the Item_splocal object constructor.
      mysql-test/t/sp.test:
        Updated test case for bug #30120.
      mysql-test/r/sp.result:
        Updated test case for bug #30120.
      33fc4ad4
  15. 28 Jul, 2007 1 commit
    • unknown's avatar
      Fixed bug #29834. · 90c5621d
      unknown authored
      Using view columns by their names during an execution of
      a prepared SELECT statement or a SELECT statement inside
      a SP caused a memory leak.
      
      
      sql/sql_base.cc:
        Fixed bug #29834.
        The find_field_in_view function has been modified to
        use the execution memory root for the Item_direct_view_ref
        objects allocation at non-first executions of
        a PS/SP instead of the statement memory.
      mysql-test/t/sp.test:
        Updated test case for bug #29834.
      mysql-test/r/sp.result:
        Updated test case for bug #29834.
      90c5621d
  16. 21 Jul, 2007 1 commit
    • unknown's avatar
      sp.test, sp.result: · 9cad4f08
      unknown authored
        Additional test case fix for bug #29338.
      
      
      mysql-test/t/sp.test:
        Additional test case fix for bug #29338.
      mysql-test/r/sp.result:
        Additional test case fix for bug #29338.
      9cad4f08
  17. 19 Jul, 2007 1 commit
    • unknown's avatar
      Fixed bug #29338. · 36f1e484
      unknown authored
      Optimization of queries with DETERMINISTIC functions in the
      WHERE clause was not effective: sequential scan was always
      used.
      Now a SF with the DETERMINISTIC flags is treated as constant
      when it's arguments are constants (or a SF doesn't has arguments).
      
      
      sql/item_func.h:
        Fixed bug #29338.
        The Item_func_sp::used_tables has been removed
        (virtual Item_func::used_tables function is enough).
        The virtual Item_func_sp::update_used_tables function
        has been added.
      sql/item_func.cc:
        Fixed bug #29338.
        The Item_func_sp::update_used_tables and the
        Item_func_sp::fix_field functions have been modified
        to take into account the DETERMINISTIC flag of SF definition.
      mysql-test/r/sp.result:
        Updated test case for bug #29338.
      mysql-test/t/sp.test:
        Updated test case for bug #29338.
      36f1e484
  18. 05 Jul, 2007 1 commit
    • unknown's avatar
      A fix and a test case for Bug#29050 Creation of a legal stored procedure · e8966dee
      unknown authored
      fails if a database is not selected prior.
      
      The problem manifested itself when a user tried to
      create a routine that had non-fully-qualified identifiers in its bodies
      and there was no current database selected.
      
      This is a regression introduced by the fix for Bug 19022:
      
      The patch for Bug 19022 changes the code to always produce a warning
      if we can't resolve the current database in the parser. 
      In this case this was not necessary, since even though the produced
      parsed tree was incorrect, we never re-use sphead
      that was obtained at first parsing of CREATE PROCEDURE.
      The sphead that is anyhow used is always obtained through db_load_routine,
      and there we change the current database to sphead->m_db before
      calling yyparse.
      
      The idea of the fix is to resolve the current database directly using 
      lex->sphead->m_db member when parsing a stored routine body, when
      such is present.
      
      This patch removes the need to reset the current database
      when loading a trigger or routine definition into SP cache.
      The redundant code will be removed in 5.1.
      
      
      mysql-test/r/sp.result:
        Update test results (Bug#29050)
      mysql-test/r/trigger.result:
        Update results.
      mysql-test/t/sp.test:
        Add a test case for Bug#29050
      mysql-test/t/trigger.test:
        Fix wrong behavior covered with tests.
      sql/sql_lex.cc:
        Implement st_lex::copy_db_to().
      sql/sql_lex.h:
        Declare st_lex::copy_db_to().
      sql/sql_parse.cc:
        Use st_lex::copy_db_to() in add_table_to_list, rather than
        THD::copy_db_to(). The former will use the database of the sphead,
        if we're parsing a stored routine, not the default database in
        THD. The default database is needed to initialize tables->db
        when the database part was not explicitly specified in the identifier.
      sql/sql_yacc.yy:
        Use st_lex::copy_db_to() in the parser, rather than
        THD::copy_db_to(). The former will use the database of the sphead,
        if we're parsing a stored routine, not the default database in
        THD.
      e8966dee
  19. 04 Jul, 2007 1 commit
    • unknown's avatar
      A fix and a teset case for Bug#28551 The warning · b1ec3b53
      unknown authored
      'No database selected' is reported when calling stored procedures
      
      Remove the offending warning introduced by the fix for Bug
      25082
      This minimal patch relies on the intrinsic knowledge of the fact that
      mysql_change_db is never called with 'force_switch' set to TRUE
      when such a warning may be needed:
       * every stored routine belongs to a database (unlike, e.g., a 
      user defined function, which does not), so if we're activating the
      database of a stored routine, it can never be NULL.
      Therefore, this branch is never called for activation.
       * if we're restoring the 'old' current database after routine
      execution is complete, we should not issue a warning, since it's OK to 
      call a routine without having previously selected the current database.
      
      TODO: 'force_switch' is an ambiguous flag, since we do not actually
      have to 'force' the switch in case of stored routines at all.
      When we activate the routine's database, we should perform
      all the checks as in case of 'use db', and so we already do (in this
      case 'force_switch' is unused).
      When we load a routine into cache, we should not use mysql_change_db
      at all, since there it's enough to call thd->reset_db(). We
      do it this way for triggers, but code for routines is different (wrongly). 
      
      TODO: bugs are lurking in replication, since it bypasses mysql_change_db
      and calls thd->[re_]set_db to set the current database.
      The latter does not change thd->db_charset, thd->sctx->db_access
      and thd->variables.collation_database (and this may have nasty side
      effects).
      
      These todo items are to be addressed in a separate patch, if at all.
      
      
      mysql-test/r/sp.result:
        Update results (Bug#28551)
      mysql-test/t/sp.test:
        Add a test case (Bug#28551)
      sql/sp.cc:
        Remove an obsolete comment.
        Replace a check with an assert.
      sql/sql_db.cc:
        Remove the offending warning introduced by the fix for Bug
        25082
        This minimal patch relies on the intrinsic knowledge of the fact that
        mysql_change_db is never called with 'force_switch' set to TRUE
        when such a warning may be needed.
      b1ec3b53
  20. 05 Jun, 2007 1 commit
    • unknown's avatar
      BUG#26976 - Missing table in merge not noted in related error msg + · 55c76592
      unknown authored
                  SHOW CREATE TABLE fails
      
      Underlying table names, that merge engine fails to open were not
      reported.
      
      With this fix CHECK TABLE issued against merge table reports all
      underlying table names that it fails to open. Other statements
      are unaffected, that is underlying table names are not included
      into error message.
      
      This fix doesn't solve SHOW CREATE TABLE issue.
      
      
      myisammrg/myrg_def.h:
        Added myrg_print_wrong_table declaration.
      myisammrg/myrg_open.c:
        If HA_OPEN_FOR_REPAIR is passed to merge engine open function,
        report names of tables that we fail to open.
      mysql-test/r/backup.result:
        Updated test result.
      mysql-test/r/key_cache.result:
        Updated test result - removed duplicate error.
      mysql-test/r/lock.result:
        Updated test result - added summary row.
      mysql-test/r/merge.result:
        A test case for BUG#26976.
      mysql-test/r/preload.result:
        Updated test result - removed duplicate error, added summary row.
      mysql-test/r/ps.result:
        Updated test result - removed duplicate error, added summary row.
      mysql-test/r/repair.result:
        Updated test result - removed duplicate error, added summary row.
      mysql-test/r/rpl_failed_optimize.result:
        Updated test result - removed duplicate error, added summary row.
      mysql-test/r/sp.result:
        Updated test result - removed duplicate error, added summary row.
      mysql-test/r/view.result:
        Updated test result - removed duplicate error, added summary row.
      mysql-test/t/merge.test:
        A test case for BUG#26976.
      sql/ha_myisam.cc:
        Do not report same error twice.
      sql/ha_myisammrg.cc:
        If HA_OPEN_FOR_REPAIR is passed to merge engine open function,
        report names of tables that we fail to open.
        
        Added dummy ha_myisammrg::check to not confuse users with
        "not implemented" error in case all underlying tables are
        fine.
      sql/ha_myisammrg.h:
         Added ha_myisammrg::check declaration.
      sql/share/errmsg.txt:
        Added ER_ADMIN_WRONG_MRG_TABLE errno. It is used instead
        of ER_WRONG_MRG_TABLE in case HA_OPEN_FOR_REPAIR is
        passed to merge engine handler open function.
      sql/sql_error.cc:
        warning_level_* are now public. It is required by mysql_admin_table to
        report message level.
      sql/sql_error.h:
        warning_level_* are now public. It is required by mysql_admin_table to
        report message level.
      sql/sql_table.cc:
        Reorder mysql_admin_table arguments to meet it's definition.
        
        Report errors that are pending in thd->warn_list as results of
        admin function.
      55c76592
  21. 01 Jun, 2007 1 commit
    • unknown's avatar
      Fix some mysqltest warnings. · d8cd88cd
      unknown authored
      mysql-test/r/sp.result:
        Update results.
      mysql-test/t/mysql.test:
        Fix a typo.
      mysql-test/t/mysqltest.test:
        Fix a typo.
      mysql-test/t/order_by.test:
        Fix a typo.
      mysql-test/t/row.test:
        Remove an unsupported command.
      mysql-test/t/sp.test:
        Fix a typo.
      mysql-test/t/subselect3.test:
        Fix  mysqltest warnings - now it warns when sees some suspicious --
        comment
      d8cd88cd
  22. 30 May, 2007 1 commit
    • unknown's avatar
      Bug #28492: subselect returns LONG in >5.0.24a and LONGLONG in <=5.0.24a · 4e9cef54
      unknown authored
      Integer values with 10 digits may or may not fit into an int column 
      (e.g. 2147483647 vs 6147483647).
      Thus when creating a temp table column for such an int we must
      use bigint instead.
      Fixed to use bigint.
      Also subsituted a "magic number" with a named constant.
      
      
      mysql-test/r/analyse.result:
        Bug #28492: Adjusted the results after having fixed the bug
      mysql-test/r/metadata.result:
        Bug #28492: test case
      mysql-test/r/olap.result:
        Bug #28492: Adjusted the results after having fixed the bug
      mysql-test/r/sp.result:
        Bug #28492: Adjusted the results after having fixed the bug
      mysql-test/r/view.result:
        Bug #28492: Adjusted the results after having fixed the bug
      mysql-test/t/metadata.test:
        Bug #28492: test case
      sql/field.h:
        Bug #28492: Replaced a magic number with a constant
      sql/sql_select.cc:
        Bug #28492: Treat integers with 10 and more digits as 
        bigint.
      4e9cef54
  23. 29 May, 2007 1 commit
    • unknown's avatar
      Bug #28605: SHOW CREATE VIEW with views using stored_procedures no · 9e06efb4
      unknown authored
       longer showing SP names.
      SHOW CREATE VIEW uses Item::print() methods to reconstruct the 
      statement text from the parse tree.
      The print() method for stored procedure calls needs allocate 
      space to print the function's quoted name.
      It was incorrectly calculating the length of the buffer needed 
      (was too short).
      Fixed to reflect the actual space needed.
      
      
      mysql-test/r/sp.result:
        Bug #28605: test case
      mysql-test/t/sp.test:
        Bug #28605: test case
      sql/item_func.cc:
        Bug #28605: fixed the string length calculation
      9e06efb4
  24. 27 Apr, 2007 1 commit
    • unknown's avatar
      Bug#21513 (SP having body starting with quoted label rendered unusable) · 1700feaa
      unknown authored
      Before this fix, the parser would sometime change where a token starts by
      altering Lex_input_string::tok_start, which later confused the code in
      sql_yacc.yy that needs to capture the source code of a SQL statement,
      like to represent the body of a stored procedure.
      
      This line of code in sql_lex.cc :
      
      case MY_LEX_USER_VARIABLE_DELIMITER:
        lip->tok_start= lip->ptr; // Skip first `
      
      would <skip the first back quote> ... and cause the bug reported.
      
      In general, the responsibility of sql_lex.cc is to *find* where token are
      in the SQL text, but is *not* to make up fake or incomplete tokens.
      With a quoted label like `my_label`, the token starts on the first quote.
      Extracting the token value should not change that (it did).
      
      With this fix, the lexical analysis has been cleaned up to not change
      lip->tok_start (in the case found for this bug).
      
      The functions get_token() and get_quoted_token() now have an extra
      parameters, used when some characters from the beginning of the token need
      to be skipped when extracting a token value, like when extracting 'AB' from
      '0xAB', for example, for a HEX_NUM token.
      
      This exposed a bad assumption in Item_hex_string and Item_bin_string,
      which has been fixed:
      
      The assumption was that the string given, 'AB', was in fact preceded in
      memory by '0x', which might be false (it can be preceded by "x'" and
      followed by "'" -- or not be preceded by valid memory at all)
      
      If a name is needed for Item_hex_string or Item_bin_string, the name is
      taken from the original and true source code ('0xAB'), and assigned in
      the select_item rule, instead of relying on assumptions related to how
      memory is used.
      
      
      mysql-test/r/sp.result:
        Lex_input_stream::tok_start must point at the real start of a token.
      mysql-test/t/sp.test:
        Lex_input_stream::tok_start must point at the real start of a token.
      sql/item.cc:
        Lex_input_stream::tok_start must point at the real start of a token.
      sql/sql_lex.cc:
        Lex_input_stream::tok_start must point at the real start of a token.
      sql/sql_yacc.yy:
        Lex_input_stream::tok_start must point at the real start of a token.
      1700feaa
  25. 12 Apr, 2007 1 commit
  26. 27 Mar, 2007 2 commits
    • unknown's avatar
      Fix for BUG#25082: default database change on trigger · 6a594ffd
      unknown authored
      execution breaks replication.
      
      When a stored routine is executed, we switch current
      database to the database, in which the routine
      has been created. When the stored routine finishes,
      we switch back to the original database.
      
      The problem was that if the original database does not
      exist (anymore) after routine execution, we raised an error.
      
      The fix is to report a warning, and switch to the NULL database.
      
      
      mysql-test/r/sp.result:
        Updated result file.
      mysql-test/t/sp.test:
        Added test case for BUG#25082.
      sql/mysql_priv.h:
        1. Change mysql_change_db() prototype;
        2. Polishing.
      sql/sp.cc:
        Polishing.
      sql/sp_head.cc:
        Polishing.
      sql/sql_db.cc:
        1. Polishing.
        2. Fix mysql_change_db().
      sql/sql_parse.cc:
        Polishing.
      sql/sql_show.cc:
        Polishing.
      6a594ffd
    • unknown's avatar
      Corrected error in test case: · e4dcf4e3
      unknown authored
      - 1.84e+15 converted to unsigned bigint should be
        18400000000000000000 < 18446744073709551615.
      - The test will still fail on windows, and is extracted
        into a new bug report.
      
      
      e4dcf4e3
  27. 22 Mar, 2007 1 commit
    • unknown's avatar
      Bug #27354 stored function in where condition was always treated as const · df3a48ea
      unknown authored
      Possible problems: function call could be eliminated from where class and only
      be evaluated once; function can be evaluated during table and item setup phase which could
      cause side effects not to be registered in binlog.
      
      Fixed with introducing func_item_sp::used_tables() returning the correct table_map constant.
      
      
      
      mysql-test/r/sp.result:
        results changed
      mysql-test/t/sp.test:
        regression test demonstrating that function's returns match where condition
        of the top-level query table.
      sql/item_func.h:
        private used_tables() method returning the correct table_bit with meaning the item is not
        a constant
      df3a48ea
  28. 16 Mar, 2007 1 commit
    • unknown's avatar
      Bug#20777 Function w BIGINT UNSIGNED shows diff. behaviour with and without --ps-protocol · ffc605aa
      unknown authored
      - Stored procedures returning unsinged values returns signed values if
        text protocol is used. The reason is that the stored proceedure item
        Item_func_sp wasn't initializing the member variables properly based
        on the information contained in the associated result field.
      - The patch is to upon field-item association, ::fix_fields, initialize
        the member variables in appropriate order.
      - Field type of an Item_func_sp was hard coded to MYSQL_TYPE_VARCHAR.
        This is changed to return the type of the actual result field.
      - Member function name sp_result_field was refactored to the more 
        appropriate init_result_field.
      - Member function name find_and_check_access was refactored to 
        sp_check_access.
      
      
      mysql-test/r/sp.result:
        - Added test
      mysql-test/t/sp.test:
        - Added test
      sql/item_func.cc:
        Bug#20777 Function w BIGINT UNSIGNED shows diff. behaviour with and without --ps-protocol
        
        - Stored procedures returning unsinged values returns signed values if
          text protocol is used. The reason is that the stored proceedure item
          Item_func_sp wasn't initializing the member variables properly based
          on the information contained in the associated result field.
        - The patch is to upon field-item association, ::fix_fields, initialize
          the member variables in appropriate order.
        - Field type of an Item_func_sp was hard coded to MYSQL_TYPE_VARCHAR.
          This is changed to to return the type of the actual result field.
        - Member function name sp_result_field was refactored to the more 
          appropriate init_result_field.
        - Member function name find_and_check_access was refactored to 
          sp_check_access.
      sql/item_func.h:
        Bug#20777 Function w BIGINT UNSIGNED shows diff. behaviour with and without --ps-protocol
        
        - Stored procedures returning unsinged values returns signed values if
          text protocol is used. The reason is that the stored proceedure item
          Item_func_sp wasn't initializing the member variables properly based
          on the information contained in the associated result field.
        - The patch is to upon field-item association, ::fix_fields, initialize
          the member variables in appropriate order.
        - Field type of an Item_func_sp was hard coded to MYSQL_TYPE_VARCHAR.
          This is changed to to return the type of the actual result field.
        - Member function name sp_result_field was refactored to the more 
          appropriate init_result_field.
        - Member function name find_and_check_access was refactored to 
          sp_check_access.
      ffc605aa
  29. 14 Mar, 2007 1 commit
    • unknown's avatar
      Bug#26503 (Illegal SQL exception handler code causes the server to crash) · 79344c7b
      unknown authored
      Before this fix, the parser would accept illegal code in SQL exceptions
      handlers, that later causes the runtime to crash when executing the code,
      due to memory violations in the exception handler stack.
      
      The root cause of the problem is instructions within an exception handler
      that jumps to code located outside of the handler. This is illegal according
      to the SQL 2003 standard, since labels located outside the handler are not
      supposed to be visible (they are "out of scope"), so any instruction that
      jumps to these labels, like ITERATE or LEAVE, should not parse.
      
      The section of the standard that is relevant for this is :
        SQL:2003 SQL/PSM (ISO/IEC 9075-4:2003)
        section 13.1 <compound statement>,
        syntax rule 4
      <quote>
        The scope of the <beginning label> is CS excluding every <SQL schema
        statement> contained in CS and excluding every
        <local handler declaration list> contained in CS. <beginning label> shall
        not be equivalent to any other <beginning label>s within that scope.
      </quote>
      
      With this fix, the C++ class sp_pcontext, which represent the "parsing
      context" tree (a.k.a symbol table) of a stored procedure, has been changed
      as follows:
      - constructors have been cleaned up, so that only building a root node for
      the tree is public; building nodes inside a tree is not public.
      - a new member, m_label_scope, indicates if a given syntactic context
      belongs to a DECLARE HANDLER block,
      - label resolution, in the method find_label(), has been changed to
      implement the restriction of scope regarding labels used in a compound
      statement.
      
      The actions in the parser, when parsing the body of a SQL exception handler,
      have been changed as follows:
      - the implementation of an exception handler (DECLARE HANDLER) now creates
      explicitly a new sp_pcontext, to isolate the code inside the handler from
      the containing compound statement context.
      - registering exception handlers as a result occurs in the parent context,
      see the rule sp_hcond_element
      - the code in sp_hcond_list has been cleaned up, to avoid code duplication
      
      In addition, the flags IN_SIMPLE_CASE and IN_HANDLER, declared in sp_head.h
      have been removed, since they are unused and broken by design (as seen with
      Bug 19194 (Right recursion in parser for CASE causes excessive stack usage,
      limitation), representing a stack in a single flag is not possible.
      
      Tests in sp-error have been added to show that illegal constructs are now
      rejected.
      
      Tests in sp have been added for code coverage, to show that ITERATE or LEAVE
      statements are legal when jumping to a label in scope, inside the body of
      an exception handler.
      
      
      mysql-test/r/sp-error.result:
        SQL Exception handlers define a parsing context for label resolution.
      mysql-test/r/sp.result:
        SQL Exception handlers define a parsing context for label resolution.
      mysql-test/t/sp-error.test:
        SQL Exception handlers define a parsing context for label resolution.
      mysql-test/t/sp.test:
        SQL Exception handlers define a parsing context for label resolution.
      sql/sp_head.cc:
        Minor cleanup
      sql/sp_head.h:
        Minor cleanup
      sql/sp_pcontext.cc:
        SQL Exception handlers define a parsing context for label resolution.
      sql/sp_pcontext.h:
        SQL Exception handlers define a parsing context for label resolution.
      sql/sql_yacc.yy:
        SQL Exception handlers define a parsing context for label resolution.
      79344c7b
  30. 07 Mar, 2007 1 commit
    • unknown's avatar
      Bug#25373: Stored functions wasn't compared correctly which leads to a wrong · 11b533b8
      unknown authored
      result.
      
      For built-in functions like sqrt() function names are hard-coded and can be
      compared by pointer. But this isn't the case for a used-defined stored
      functions - names there are dynamical and should be compared as strings.
      
      Now the Item_func::eq() function employs my_strcasecmp() function to compare
      used-defined stored functions names.
      
      
      mysql-test/t/sp.test:
        Added a test case for bug#25373: Stored functions wasn't compared correctly which leads to a wrong result.
      mysql-test/r/sp.result:
        Added a test case for bug#25373: Stored functions wasn't compared correctly which leads to a wrong result.
      sql/item_func.cc:
        Bug#25373: Stored functions wasn't compared correctly which leads to a wrong
        result.
        Now the Item_func::eq() function employs my_strcasecmp() function to compare
        used-defined stored functions names.
      11b533b8
  31. 06 Mar, 2007 1 commit
    • unknown's avatar
      Bug#8407 (Stored functions/triggers ignore exception handler) · 266a7fff
      unknown authored
      Bug 18914 (Calling certain SPs from triggers fail)
      Bug 20713 (Functions will not not continue for SQLSTATE VALUE '42S02')
      Bug 21825 (Incorrect message error deleting records in a table with a
        trigger for inserting)
      Bug 22580 (DROP TABLE in nested stored procedure causes strange dependency
        error)
      Bug 25345 (Cursors from Functions)
      
      
      This fix resolves a long standing issue originally reported with bug 8407,
      which affect the behavior of Stored Procedures, Stored Functions and Trigger
      in many different ways, causing symptoms reported by all the bugs listed.
      In all cases, the root cause of the problem traces back to 8407 and how the
      server locks tables involved with sub statements.
      
      Prior to this fix, the implementation of stored routines would:
      - compute the transitive closure of all the tables referenced by a top level
      statement
      - open and lock all the tables involved
      - execute the top level statement
      "transitive closure of tables" means collecting:
      - all the tables,
      - all the stored functions,
      - all the views,
      - all the table triggers
      - all the stored procedures
      involved, and recursively inspect these objects definition to find more
      references to more objects, until the list of every object referenced does
      not grow any more.
      This mechanism is known as "pre-locking" tables before execution.
      The motivation for locking all the tables (possibly) used at once is to
      prevent dead locks.
      
      One problem with this approach is that, if the execution path the code
      really takes during runtime does not use a given table, and if the table is
      missing, the server would not execute the statement.
      This in particular has a major impact on triggers, since a missing table
      referenced by an update/delete trigger would prevent an insert trigger to run.
      
      Another problem is that stored routines might define SQL exception handlers
      to deal with missing tables, but the server implementation would never give
      user code a chance to execute this logic, since the routine is never
      executed when a missing table cause the pre-locking code to fail.
      
      With this fix, the internal implementation of the pre-locking code has been
      relaxed of some constraints, so that failure to open a table does not
      necessarily prevent execution of a stored routine.
      
      In particular, the pre-locking mechanism is now behaving as follows:
      
      1) the first step, to compute the transitive closure of all the tables
      possibly referenced by a statement, is unchanged.
      
      2) the next step, which is to open all the tables involved, only attempts
      to open the tables added by the pre-locking code, but silently fails without
      reporting any error or invoking any exception handler is the table is not
      present. This is achieved by trapping internal errors with
      Prelock_error_handler
      
      3) the locking step only locks tables that were successfully opened.
      
      4) when executing sub statements, the list of tables used by each statements
      is evaluated as before. The tables needed by the sub statement are expected
      to be already opened and locked. Statement referencing tables that were not
      opened in step 2) will fail to find the table in the open list, and only at
      this point will execution of the user code fail.
      
      5) when a runtime exception is raised at 4), the instruction continuation
      destination (the next instruction to execute in case of SQL continue
      handlers) is evaluated.
      This is achieved with sp_instr::exec_open_and_lock_tables()
      
      6) if a user exception handler is present in the stored routine, that
      handler is invoked as usual, so that ER_NO_SUCH_TABLE exceptions can be
      trapped by stored routines. If no handler exists, then the runtime execution
      will fail as expected.
      
      With all these changes, a side effect is that view security is impacted, in
      two different ways.
      
      First, a view defined as "select stored_function()", where the stored
      function references a table that may not exist, is considered valid.
      The rationale is that, because the stored function might trap exceptions
      during execution and still return a valid result, there is no way to decide
      when the view is created if a missing table really cause the view to be invalid.
      
      Secondly, testing for existence of tables is now done later during
      execution. View security, which consist of trapping errors and return a
      generic ER_VIEW_INVALID (to prevent disclosing information) was only
      implemented at very specific phases covering *opening* tables, but not
      covering the runtime execution. Because of this existing limitation,
      errors that were previously trapped and converted into ER_VIEW_INVALID are
      not trapped, causing table names to be reported to the user.
      This change is exposing an existing problem, which is independent and will
      be resolved separately.
      
      
      mysql-test/r/information_schema_db.result:
        Revised the pre-locking code implementation, aligned the tests.
      mysql-test/r/sp-error.result:
        Revised the pre-locking code implementation, aligned the tests.
      mysql-test/r/sp.result:
        Revised the pre-locking code implementation, aligned the tests.
      mysql-test/r/trigger.result:
        Revised the pre-locking code implementation, aligned the tests.
      mysql-test/r/view.result:
        Revised the pre-locking code implementation, aligned the tests.
      mysql-test/t/sp-error.test:
        Revised the pre-locking code implementation, aligned the tests.
      mysql-test/t/sp.test:
        Revised the pre-locking code implementation, aligned the tests.
      mysql-test/t/trigger.test:
        Revised the pre-locking code implementation, aligned the tests.
      sql/lock.cc:
        table->placeholder now checks for schema_table
      sql/mysqld.cc:
        my_message_sql(): invoke internal exception handlers
      sql/sp_head.cc:
        exec_open_and_lock_tables(): open and lock tables, or return the
        continuation destination of this instruction
      sql/sp_head.h:
        exec_open_and_lock_tables(): open and lock tables, or return the
        continuation destination of this instruction
      sql/sql_base.cc:
        Prelock_error_handler: delay open table errors until execution
      sql/sql_class.cc:
        THD: add internal error handler, as an exception mechanism.
      sql/sql_class.h:
        THD: add internal error handler, as an exception mechanism.
      sql/sql_update.cc:
        table->placeholder now checks for schema_table
      sql/table.cc:
        st_table_list::hide_view_error(): masked more errors for view security
      sql/table.h:
        table->placeholder now checks for schema_table, and unopened tables
      266a7fff
  32. 19 Feb, 2007 1 commit
    • unknown's avatar
      Bug#18743: Several test cases fails if "classic" configuration in 5.0 · db36a2aa
      unknown authored
      The problem happened because those tests were using "cp932" and "ucs2" without checking whether these character sets are available. This fix moves test parts to make character set specific parts be tested only if they are:
      - some parts were moved to "ctype_ucs.test" and "ctype_cp932.test"
      - some parts were moved to the newly added tests "innodb-ucs2.test", "mysqlbinglog-cp932.test" and "sp-ucs2.test"
      
      
      mysql-test/r/ctype_cp932.result:
        Moved cp932-specific test case from mysql.test
      mysql-test/r/innodb.result:
        Moved ucs2-specific test cases to innodb-ucs2.test
      mysql-test/r/mysql.result:
        Move cp932-specific test cases to ctype_cp932.test
      mysql-test/r/mysqlbinlog.result:
        Moved cp932-specific test case to mysqlbinlog-cp932.test
      mysql-test/r/sp.result:
        Moved ucs2-specific test case to sp-ucs2.test
      mysql-test/t/ctype_cp932.test:
        Moved cp932-specific test case from mysql.test
      mysql-test/t/ctype_ucs2_def-master.opt:
        Use the comma-separated list of character sets to avoid mysql-test errors when ucs2 is not available in the server
      mysql-test/t/ctype_ucs2_def.test:
        Added requirement for ucs2 in the server
      mysql-test/t/innodb.test:
        Moved ucs2-specific test cases to innodb-ucs2.test
      mysql-test/t/mysql.test:
        Move cp932-specific test cases to ctype_cp932.test
      mysql-test/t/mysqlbinlog.test:
        Moved cp932-specific test case to mysqlbinlog-cp932.test
      mysql-test/t/sp.test:
        Moved ucs2-specific test case to sp-ucs2.test
      sql/mysqld.cc:
        Allow specifying several character sets for test purposes, to make "mysqld" start even if the character set being tested is not compiled:
        mysqld --default-character-set=ucs2,latin1
        The first available character set will be chosen.
      mysql-test/r/innodb-ucs2.result:
        New BitKeeper file ``mysql-test/r/innodb-ucs2.result''
      mysql-test/r/mysqlbinlog-cp932.result:
        New BitKeeper file ``mysql-test/r/mysqlbinlog-cp932.result''
      mysql-test/r/sp-ucs2.result:
        New BitKeeper file ``mysql-test/r/sp-ucs2.result''
      mysql-test/t/innodb-ucs2.test:
        New BitKeeper file ``mysql-test/t/innodb-ucs2.test''
      mysql-test/t/mysqlbinlog-cp932.test:
        New BitKeeper file ``mysql-test/t/mysqlbinlog-cp932.test''
      mysql-test/t/sp-ucs2.test:
        New BitKeeper file ``mysql-test/t/sp-ucs2.test''
      db36a2aa
  33. 14 Dec, 2006 1 commit
    • unknown's avatar
      Fix for bug #24117 "server crash on a FETCH with a cursor on a table which is... · 5b712814
      unknown authored
      Fix for bug #24117 "server crash on a FETCH with a cursor on a table which is not in the table cache"
      
      Problem:
      When creating a temporary field for a temporary table in create_tmp_field_from_field(), a resulting field is created as an exact copy of an original one (in Field::new_field()). However, Field_enum and Field_set contain a pointer (typelib) to memory allocated in the parent table's MEM_ROOT, which under some circumstances may be deallocated later by the time a temporary table is used.
      
      Solution:
      Override the new_field() method for Field_enum and Field_set and create a separate copy of the typelib structure in there.
      
      
      include/typelib.h:
        Added copy_typelib() declaration
      mysql-test/r/sp.result:
        Added a testcase for bug #24117 "server crash on a FETCH with a cursor on a table which is not in the table cache"
      mysql-test/t/sp.test:
        Added a testcase for bug #24117 "server crash on a FETCH with a cursor on a table which is not in the table cache"
      mysys/typelib.c:
        Added copy_typelib() definition
      sql/field.cc:
        Create a copy of the internal 'typelib' structure when copying Field_enum of Field_set objects.
      sql/field.h:
        Override new_field method in Field_enum (and Field_set) to copy the typelib structure.
      5b712814
  34. 11 Dec, 2006 1 commit
    • unknown's avatar
      Post-merge fixes for Bug#4968 "Stored procedure crash if cursor opened · a8103a89
      unknown authored
      on altered table" and Bug#19733 "Repeated alter, or repeated 
      create/drop, fails"
      
      
      mysql-test/r/ps.result:
        Post-merge fixes: update results with new tests.
      mysql-test/r/sp.result:
        Post-merge fixes: update results.
      mysql-test/t/ps.test:
        Add more test cases for Bug#4968 and related.
      mysql-test/t/sp.test:
        A post-merge fix: add more testcases for Bug#4968 and related.
      sql/sql_insert.cc:
        Post-merge fixes: update comments, fix errors of the manual merge.
      sql/sql_lex.cc:
        Fix a manual merge error.
      sql/sql_parse.cc:
        Fix a few errors of the manual merge, style.
      sql/sql_table.cc:
        Post-merge fixes, fix a few errors of the manual merge, fix style.
      sql/sql_yacc.yy:
        A post-merge fix.
      a8103a89
  35. 14 Nov, 2006 1 commit
    • unknown's avatar
      Fix for bug#23760 ROW_COUNT() and store procedure not owrking together · 645aac54
      unknown authored
      The problem was that THD::row_count_func was zeroed too. It was zeroed
      as a fix for bug 4905 "Stored procedure doesn't clear for "Rows affected"
      However, the proper solution is not to zero, because THD::row_count_func has
      been set to -1 already in mysql_execute_command(), a later fix, which obsoletes
      the incorrect fix of #4095
      
      
      mysql-test/r/sp.result:
        update result
      mysql-test/t/sp.test:
        test for bug#23760 ROW_COUNT() and store procedure not owrking together
      sql/sql_parse.cc:
        Remove zeroing for thd->row_count_func
        The fix for #4905 wasn't right. Now, it's ok without this zeroing
        because if there was an error THD::
      645aac54
  36. 19 Oct, 2006 1 commit
    • unknown's avatar
      Bug#20028 (Function with select return no data) · 5bd58f3e
      unknown authored
      This patch reverts a change introduced by Bug 6951, which incorrectly
      set thd->abort_on_warning for stored procedures.
      
      As per internal discussions about the SQL_MODE=TRADITIONAL,
      the correct behavior is to *not* abort on warnings even inside an INSERT/UPDATE
      trigger.
      
      Tests for Stored Procedures, Stored Functions, Triggers involving SQL_MODE
      have been included or revised, to reflect the intended behavior.
      
      (reposting approved patch, to work around source control issues, no review needed)
      
      
      mysql-test/include/sp-vars.inc:
        Tests for SQL_MODE='TRADITIONAL'
      mysql-test/r/sp-vars.result:
        Tests for SQL_MODE='TRADITIONAL'
      mysql-test/r/sp.result:
        Tests for SQL_MODE='TRADITIONAL'
      mysql-test/r/trigger.result:
        Tests for SQL_MODE='TRADITIONAL'
      mysql-test/t/sp-vars.test:
        Tests for SQL_MODE='TRADITIONAL'
      mysql-test/t/sp.test:
        Tests for SQL_MODE='TRADITIONAL'
      mysql-test/t/trigger.test:
        Tests for SQL_MODE='TRADITIONAL'
      sql/sp_head.cc:
        For SQL_MODE='TRADITIONAL',
        thd->abort_on_warning should be set only when assigning a *column*
      5bd58f3e
  37. 09 Oct, 2006 1 commit
    • unknown's avatar
      Bug#21462 (Stored procedures with no arguments require parenthesis) · e1e0f829
      unknown authored
      The syntax of the CALL statement, to invoke a stored procedure, has been
      changed to make the use of parenthesis optional in the argument list.
      With this change, "CALL p;" is equivalent to "CALL p();".
      
      While the SQL spec does not explicitely mandate this syntax, supporting it
      is needed for practical reasons, for integration with JDBC / ODBC connectors.
      
      Also, warnings in the sql/sql_yacc.yy file, which were not reported by Bison 2.1
      but are now reported by Bison 2.2, have been fixed.
      
      The warning found were:
      bison -y -p MYSQL  -d --debug --verbose sql_yacc.yy
      sql_yacc.yy:653.9-18: warning: symbol UNLOCK_SYM redeclared
      sql_yacc.yy:656.9-17: warning: symbol UNTIL_SYM redeclared
      sql_yacc.yy:658.9-18: warning: symbol UPDATE_SYM redeclared
      sql_yacc.yy:5169.11-5174.11: warning: unused value: $2
      sql_yacc.yy:5208.11-5220.11: warning: unused value: $5
      sql_yacc.yy:5221.11-5234.11: warning: unused value: $5
      conflicts: 249 shift/reduce
      
      "unused value: $2" correspond to the $$=$1 assignment in the 1st {} block
      in table_ref -> join_table {} {},
      which does not procude a result ($$) for the rule but an intermediate $2
      value for the action instead.
      "unused value: $5" are similar, with $$ assignments in {} actions blocks
      which are not for the final reduce.
      
      
      mysql-test/r/sp.result:
        New test case for Bug#21462
      mysql-test/t/sp.test:
        New test case for Bug#21462
      sql/sql_yacc.yy:
        "CALL p;" syntax for calling a stored procedure
        Fixed bison 2.2 warnings.
      e1e0f829