An error occurred fetching the project authors.
  1. 08 Feb, 2008 1 commit
    • unknown's avatar
      Bug#33798 prepared statements improperly handle large unsigned ints · 7d98c21c
      unknown authored
      The unsignedness of large integer user variables was not being
      properly preserved when feeded to prepared statements. This was
      happening because the unsigned flags wasn't being updated when
      converting the user variable is converted to a parameter.
      
      The solution is to copy the unsigned flag when converting the
      user variable to a parameter and take the unsigned flag into
      account when converting the integer to a string.
      
      
      mysql-test/r/binlog.result:
        Add test case result for Bug#33798
      mysql-test/r/ps.result:
        Add test case result for Bug#33798
      mysql-test/t/binlog.test:
        Add test case for Bug#33798
      mysql-test/t/ps.test:
        Add test case for Bug#33798
      sql/item.cc:
        Take the unsigned flag into account when converting the
        user variable.
      7d98c21c
  2. 10 Nov, 2007 1 commit
  3. 07 Nov, 2007 1 commit
    • unknown's avatar
      Fix for bug #32137: prepared statement crash with str_to_date in update clause · c7191f90
      unknown authored
      Problem: calling non-constant argument's val_xxx() methods 
      in the ::fix_length_and_dec() is inadmissible.
      
      Fix: call the method only for constant arguments.
      
      
      mysql-test/r/ps.result:
        Fix for bug #32137: prepared statement crash with str_to_date in update clause
          - test result.
      mysql-test/t/ps.test:
        Fix for bug #32137: prepared statement crash with str_to_date in update clause
          - test case.
      sql/item_timefunc.cc:
        Fix for bug #32137: prepared statement crash with str_to_date in update clause
          - call argument's val_str() only for constant items in the 
            Item_func_str_to_date::fix_length_and_dec().
      c7191f90
  4. 29 Aug, 2007 1 commit
  5. 18 May, 2007 1 commit
    • unknown's avatar
      Fox for bug #28509: strange behaviour: passing a decimal value to PS · 6249d57d
      unknown authored
      Set parameter's type to Item::DECIMAL_ITEM assigning a decimal value.
      
      
      mysql-test/r/ps.result:
        Fox for bug #28509: strange behaviour: passing a decimal value to PS
          - test result.
      mysql-test/t/ps.test:
        Fox for bug #28509: strange behaviour: passing a decimal value to PS
          - test case.
      sql/item.cc:
        Fox for bug #28509: strange behaviour: passing a decimal value to PS
          - set Item_param::item_type to Item::DECIMAL_ITEM in case of DECIMAL_RESULT variable.
          - removed redundant item_result_type assignments as it's set before.
      6249d57d
  6. 15 May, 2007 1 commit
  7. 14 May, 2007 1 commit
    • unknown's avatar
      Fixed bug #27937: crash for the the second execution of a prepared · fca58c95
      unknown authored
      statement from a UNION query with ORDER BY an expression containing
      RAND().
      The crash happened because the global order by list in the union query
      was not re-initialized for execution.
      (Local order by lists were re-initialized though).
      
      
      
      mysql-test/r/ps.result:
        Added a test case for bug #27937.
      mysql-test/t/ps.test:
        Added a test case for bug #27937.
      sql/sql_union.cc:
        Fixed bug #27937: crash for the the second execution of a prepared
        statement from a UNION query with ORDER BY an expression containing
        RAND().
        The crash happened because the global order by list in the union query
        was not re-initialized for execution.
        (Local order by lists were re-initialized though).
        Added re-initialization of the global order by list in the function
        st_select_lex_unit::init_prepare_fake_select_lex.
      fca58c95
  8. 11 May, 2007 1 commit
    • unknown's avatar
      Cleanup: now that we have Lex_input_stream, finish the transition · a0567199
      unknown authored
      by moving yet another relevant flag to it from struct LEX.
      
      
      mysql-test/r/ps.result:
        Update result.
      mysql-test/r/ps_1general.result:
        Update result.
      mysql-test/t/ps.test:
        New error code.
      mysql-test/t/ps_1general.test:
        New error code.
      sql/sql_lex.cc:
        Move stmt_prepare_mode to Lex_input_stream.
      sql/sql_lex.h:
        Move stmt_prepare_mode to class Lex_input_stream
      sql/sql_prepare.cc:
        Move stmt_prepare_mode to Lex_input_stream
      sql/sql_yacc.yy:
        Remove dead code.
      a0567199
  9. 01 Feb, 2007 1 commit
    • unknown's avatar
      Valgrind error fixes · 2df29225
      unknown authored
      Notes:
      This patch doesn't fix all issues in the tree and we need jani's fix for that
      This patch shoud not be merged into 5.0
      
      
      mysql-test/r/ps.result:
        result fix
      mysql-test/r/symlink.result:
        result fix
      mysql-test/t/ps.test:
        test is moved to 'symlink' test
      mysql-test/t/symlink.test:
        test from 'ps' test
      sql/field_conv.cc:
        valgrind error fix: backport from 5.0
      sql/mysqld.cc:
        release of ssl_context
      vio/viosslfactories.c:
        release of ssl_context
      mysql-test/valgrind.supp:
        New BitKeeper file ``mysql-test/valgrind.supp''
        This file is backported from 5.0, added suppressing of OpenSSL errors
      2df29225
  10. 23 Jan, 2007 1 commit
    • unknown's avatar
      Proposed fix for bug#24491 "using alias from source table in insert ... · 1dead07d
      unknown authored
      on duplicate key".
      
      INSERT ... SELECT ... ON DUPLICATE KEY UPDATE which was used in
      stored routine or as prepared statement and which in its ON DUPLICATE
      KEY clause erroneously tried to assign value to a column mentioned only
      in its SELECT part was properly emitting error on the first execution
      but succeeded on the second and following executions.
      
      Code which is responsible for name resolution of fields mentioned in
      UPDATE clause (e.g. see select_insert::prepare()) modifies table list
      and Name_resolution_context used in this process. It uses
      Name_resolution_context_state::save_state/restore_state() to revert
      these modifications. Unfortunately those two methods failed to revert
      properly modifications to TABLE_LIST::next_name_resolution_table
      and this broke name resolution process for successive executions.
      
      This patch fixes Name_resolution_context_state::save_state/restore_state()
      in such way that it properly handles TABLE_LIST::next_name_resolution_table.
      
      
      mysql-test/r/ps.result:
        Added test case for bug#24491 "using alias from source table in insert ...
        on duplicate key"
      mysql-test/r/sp-error.result:
        Added test case for bug#24491 "using alias from source table in insert ...
        on duplicate key"
      mysql-test/t/ps.test:
        Added test case for bug#24491 "using alias from source table in insert ...
        on duplicate key"
      mysql-test/t/sp-error.test:
        Added test case for bug#24491 "using alias from source table in insert ...
        on duplicate key"
      sql/item.h:
        Name_resolution_context::save_state/restore_state():
          At the moment these methods are used only by code implementing
          INSERT and INSERT ... SELECT statements. This code doesn't modify
         'next_name_resolution_table' member of table list element
          corresponding to the first table of SELECT clause (pointed by
          'first_name_resolution_table'). But it modifies table list element
          corresponding to the target table of INSERT (pointed by 'table_list')
          So these methods were changed to reflect this.
      1dead07d
  11. 19 Jan, 2007 2 commits
  12. 17 Jan, 2007 1 commit
    • unknown's avatar
      Fix a ps.test failure in 5.0-runtime tree. · 06bc6836
      unknown authored
      mysql-test/r/ps.result:
        Update result files.
      mysql-test/t/ps.test:
        Disable result ouptut of SHOW CREATE TABLE: DATA DIRECTORY option
        may be present or absent from the output depending on the build
        otpions and the operating system, so the output is not consistent
        across supported platforms.
      sql/mysqld.cc:
        Remove a tricky #ifdef dependency of --use-symbolic-links on PURIFY
        added in 2002: DEBUG options should not influence server functionality.
        This backfired by producing different output of SHOW CREATE TABLE
        depending on the build options (see also Bug#25677 "With 
        --skip-symbolic-links option on, DATA DIRECTORY clause
        is silently ignored".
      06bc6836
  13. 16 Jan, 2007 1 commit
    • unknown's avatar
      A fix for the broken 4.1-runtime tree. · 9cff68bb
      unknown authored
      mysql-test/t/backup.test:
        Backport a patch for sporadically failing myisam.test (and now ps.test)
        from 5.0. The cause was in backup.test not cleaning up tables in
        mysqltest-vardir/tmp after itself.
      mysql-test/t/ps.test:
        Add additional protection against possible failure in the middle of
        backup.test
      9cff68bb
  14. 14 Dec, 2006 1 commit
    • unknown's avatar
      Fixed bug #25027. · cbd1bd90
      unknown authored
      Blocked evaluation of constant objects of the classes
      Item_func_is_null and Item_is_not_null_test at the
      prepare phase in the cases when the objects used subqueries. 
      
      
      mysql-test/r/ps.result:
        Extended test case for bug #25027.
      mysql-test/t/ps.test:
        Extended test case for bug #25027.
      sql/sql_lex.cc:
        Returned back the assertion in st_select_lex_unit::set_limit,
        removed by the previous commit for this bug.
      cbd1bd90
  15. 13 Dec, 2006 1 commit
    • unknown's avatar
      Fixed bug #25027. · 2f78d5ca
      unknown authored
      Removed an assertion that was not valid for the cases where the query
      in a prepared statement contained a single-row non-correlated
      subquery that was used as an argument of the IS NULL predicate.
      
      
      mysql-test/r/ps.result:
        Added a test case for bug #25027.
      mysql-test/t/ps.test:
        Added a test case for bug #25027.
      2f78d5ca
  16. 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
  17. 07 Dec, 2006 1 commit
    • unknown's avatar
      A fix and test cases for · e47ded81
      unknown authored
      Bug#4968 "Stored procedure crash if cursor opened on altered table"
      Bug#19733 "Repeated alter, or repeated create/drop, fails"
      Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from 
      stored procedure."
      Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing"
      Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server"
      
      Test cases for bugs 4968, 19733, 6895 will be added in 5.0.
      
      Re-execution of CREATE DATABASE, CREATE TABLE and ALTER TABLE 
      statements in stored routines or as prepared statements caused
      incorrect results (and crashes in versions prior to 5.0.25).
      In 5.1 the problem occured only for CREATE DATABASE, CREATE TABLE
      SELECT and CREATE TABLE with INDEX/DATA DIRECTOY options).
      
      The problem of bugs 4968, 19733, 19282 and 6895 was that functions
      mysql_prepare_table, mysql_create_table and mysql_alter_table were not
      re-execution friendly: during their operation they used to modify contents
      of LEX (members create_info, alter_info, key_list, create_list),
      thus making the LEX unusable for the next execution.
      In particular, these functions removed processed columns and keys from
      create_list, key_list and drop_list. Search the code in sql_table.cc 
      for drop_it.remove() and similar patterns to find evidence.
      
      The fix is to supply to these functions a usable copy of each of the
      above structures at every re-execution of an SQL statement. 
      
      To simplify memory management, LEX::key_list and LEX::create_list
      were added to LEX::alter_info, a fresh copy of which is created for
      every execution.
      
      The problem of crashing bug 22060 stemmed from the fact that the above 
      metnioned functions were not only modifying HA_CREATE_INFO structure in 
      LEX, but also were changing it to point to areas in volatile memory of 
      the execution memory root.
       
      The patch solves this problem by creating and using an on-stack
      copy of HA_CREATE_INFO (note that code in 5.1 already creates and
      uses a copy of this structure in mysql_create_table()/alter_table(),
      but this approach didn't work well for CREATE TABLE SELECT statement).
      
      
      mysql-test/r/ps.result:
        Update test results (Bug#19182, Bug#22060)
      mysql-test/t/ps.test:
        Add a test case for Bug#19182, Bug#22060 (4.1-only parts)
      sql/mysql_priv.h:
        LEX::key_list and LEX::create_list were moved to LEX::alter_info.
        Update declarations to use LEX::alter_info instead of these two
        members.
      sql/sql_class.h:
        Replace pair<columns, keys> with an instance of Alter_info in
        select_create constructor. We create a new copy of Alter_info
        each time we re-execute SELECT .. CREATE prepared statement.
      sql/sql_insert.cc:
        Adjust to a new signature of create_table_from_items.
      sql/sql_lex.cc:
        Implement Alter_info::Alter_info that would make a "deep" copy
        of all definition lists (keys, columns).
      sql/sql_lex.h:
        Move key_list and create_list to class Alter_info. Implement
        Alter_info::Alter_info that can be used with PS and SP.
      sql/sql_list.h:
        Implement a copy constructor of class List that makes a deep copy
        of all list nodes.
      sql/sql_parse.cc:
        Adjust to new signatures of mysql_create_table, mysql_alter_table,
        select_create. Functions mysql_create_index and mysql_drop_index has
        become identical after initialization of alter_info was moved to the 
        parser, and were merged. Flag enable_slow_log was not updated for 
        SQLCOM_DROP_INDEX, which is a bug. Just like CREATE INDEX, DROP INDEX
        is currently done via complete table rebuild and is rightfully a slow
        administrative statement.
      sql/sql_show.cc:
        Adjust mysqld_show_create_db to a new signature.
      sql/sql_table.cc:
        Adjust mysql_alter_table, mysql_recreate_table, mysql_create_table,
        mysql_prepare_table to new signatures.
      sql/sql_yacc.yy:
        LEX::key_list and LEX::create_list moved to class Alter_info
      e47ded81
  18. 29 Nov, 2006 1 commit
    • unknown's avatar
      Bug#20327: Marking of a wrong field leads to a wrong result on select with view, · fe499575
      unknown authored
      prepared statement and subquery.
      
      When a field of a view from an outer select is resolved the find_field_in_view
      function creates an Item_direct_view_ref object that references the 
      corresponding view underlying field. After that the view_ref is marked
      as a dependent one. While resolving view underlying field it also get
      marked as a dependent one due to current_select still points to the subselect.
      Marking the view underlying field is wrong and lead to attaching conditions
      to a wrong table and thus to the wrong result of the whole statement.
      
      Now mark_select_range_as_dependent() function isn't called for fields from a 
      view underlying table.
      
      
      sql/sql_base.cc:
        Bug#20327: Marking of a wrong field leads to a wrong result on select with view, prepared statement and subquery.
        
        Now mark_select_range_as_dependent() function isn't called for fields from a
        view underlying table.
      mysql-test/r/ps.result:
        Added a test case for bug#20327: Marking of a wrong field leads to a wrong result on select with view, prepared statement and subquery.
      mysql-test/t/ps.test:
        Added a test case for bug#20327: Marking of a wrong field leads to a wrong result on select with view,prepared statement and subquery.
      fe499575
  19. 21 Nov, 2006 2 commits
    • unknown's avatar
      Fix after manual merge. · fdc37f06
      unknown authored
      mysql-test/r/ps.result:
        Fix after manual merge: update for different error message.
      mysql-test/t/ps.test:
        Fix after manual merge: use right error codes.
      fdc37f06
    • unknown's avatar
      BUG#23159: prepared_stmt_count should be status variable · 7a45fb54
      unknown authored
      Make Prepared_stmt_count a global status variable, accessible via
      SHOW STATUS LIKE 'Prepared_stmt_count';.  Documentation should be
      updated.
      
      
      mysql-test/r/ps.result:
        Update result for bug#16365: Prepared Statements: DoS with too many
        open statements, according to bug#23159: prepared_stmt_count should be
        status variable.
      mysql-test/t/ps.test:
        Update test case for bug#16365: Prepared Statements: DoS with too many
        open statements, according to bug#23159: prepared_stmt_count should be
        status variable.
      sql/mysqld.cc:
        Add Prepared_stmt_count as global status variable.
      sql/set_var.cc:
        Remove prepared_stmt_count as system variable.
      7a45fb54
  20. 19 Oct, 2006 1 commit
    • unknown's avatar
      BUG#21856: Prepared Statements: crash if bad create · ef2d2165
      unknown authored
      When statement to be prepared contained CREATE PROCEDURE, CREATE FUNCTION
      or CREATE TRIGGER statements with a syntax error in it, the preparation
      would fail with syntax error message, but the memory could be corrupted.
      
      The problem occurred because we switch memroot when parse stored
      routine or trigger definitions, and on parse error we restored the
      original memroot only after performing some memory operations.  In more
      detail:
       - prepared statement would activate its own memory root to parse
         the definition of the stored procedure.
       - SP would reset this memory root with its own memory root to
         parse SP statements
       - a syntax error would happen
       - prepared statement would restore the original memory root
       - stored procedure would restore what it thinks was the original
         memory root, but actually was the statement memory root.
      That led to double free - in destruction of the statement and in
      a next call to mysql_parse().
      
      The solution is to restore memroot right after the failed parsing.
      
      
      mysql-test/r/ps.result:
        Add result for bug#21856: Prepared Statements: crash if bad create.
      mysql-test/t/ps.test:
        Add test case for bug#21856: Prepared Statements: crash if bad create.
      sql/sql_parse.cc:
        On parse error if thd->lex->sphead is set we have to free sp_head object
        to restore statement memroot, if it was switched during parsing.
        
        The change here is for safety, currently query_cache_abort() and
        lex->unit.cleanup() calls do not use current memroot.
      sql/sql_prepare.cc:
        On parse error if thd->lex->sphead is set we have to free sp_head object
        to restore statement memroot, if it was switched during parsing.
      ef2d2165
  21. 12 Oct, 2006 1 commit
    • unknown's avatar
      Bug #19764: SHOW commands end up in the slow log as table scans · 99d42667
      unknown authored
      Do not consider SHOW commands slow queries, just because they don't use proper indexes.
      
      This bug fix is not needed in 5.1, and the code changes will be null merged.  However, the test cases will be propogated up to 5.1.
      
      
      mysql-test/t/show_check-master.opt:
        Rename: BitKeeper/deleted/.del-show_check-master.opt -> mysql-test/t/show_check-master.opt
      mysql-test/r/ps.result:
        Add test case for bug 19764
      mysql-test/r/show_check.result:
        Add test case for bug 19764
      mysql-test/r/union.result:
        Adjust test case results based on bug #19764 changes
      mysql-test/t/ps.test:
        Add test case for bug 19764
      mysql-test/t/show_check.test:
        Add test case for bug 19764
      sql/sql_parse.cc:
        Do not log SHOW commands as slow queries just because they don't use indexes.
      sql/sql_prepare.cc:
        Save stmt_backup.lex->orig_sql_command for use in log_slow_statement()
      mysql-test/t/ps-master.opt:
        Add log-slow-queries and --log-queries-not-using indexes, to test bug #19764
      99d42667
  22. 10 Oct, 2006 1 commit
    • unknown's avatar
      BUG#21354: (COUNT(*) = 1) not working in SELECT inside prepared · 3177e8eb
      unknown authored
                 statement.
      
      The problem was that during statement re-execution if the result was
      empty the old result could be returned for group functions.
      
      The solution is to implement proper cleanup() method in group
      functions.
      
      
      mysql-test/r/ps.result:
        Add result for bug#21354: (COUNT(*) = 1) not working in SELECT inside
        prepared statement.
      mysql-test/t/func_gconcat.test:
        Add a comment that the test case is from bug#836.
      mysql-test/t/ps.test:
        Add test case for bug#21354: (COUNT(*) = 1) not working in SELECT inside
        prepared statement.
      sql/item_sum.cc:
        Call clear() in Item_sum_count::cleanup().
      sql/item_sum.h:
        Add comments.
        Add proper cleanup() methods.
        Change Item_sum::no_rows_in_result() to call clear() instead of reset(),
        as the latter also issues add(), and there is nothing to add when there
        are no rows in result.
      3177e8eb
  23. 03 Oct, 2006 1 commit
    • unknown's avatar
      Update mysqltest to latest version · 9368c7bc
      unknown authored
       - ie. backport from 5.1
       - also update testcase error dected by new version
      
      
      mysql-test/include/show_msg.inc:
        BitKeeper file /home/msvensson/mysql/same_tools/my41-same_tools/mysql-test/include/show_msg.inc
      mysql-test/include/show_msg80.inc:
        BitKeeper file /home/msvensson/mysql/same_tools/my41-same_tools/mysql-test/include/show_msg80.inc
      BitKeeper/deleted/.del-rpl_chain_temp_table.test:
        Delete: mysql-test/t/rpl_chain_temp_table.test
      BitKeeper/deleted/.del-rpl_chain_temp_table.result:
        Delete: mysql-test/r/rpl_chain_temp_table.result
      BitKeeper/deleted/.del-rpl_failsafe.result:
        Delete: mysql-test/r/rpl_failsafe.result
      BitKeeper/deleted/.del-rpl_failsafe.test:
        Delete: mysql-test/t/rpl_failsafe.test
      BitKeeper/deleted/.del-rpl_heap.test:
        Delete: mysql-test/t/rpl_heap.test
      BitKeeper/deleted/.del-rpl_heap.result:
        Delete: mysql-test/r/rpl_heap.result
      BitKeeper/deleted/.del-rpl000018.result:
        Delete: mysql-test/r/rpl000018.result
      BitKeeper/deleted/.del-rpl000018.test:
        Delete: mysql-test/t/rpl000018.test
      client/Makefile.am:
        Link mysqltest with mysys/my_copy.c
      client/mysqltest.c:
        Update mysqltest to latest version
      mysql-test/include/have_multi_ndb.inc:
        Remove old syntax "@filename" in favor of "--require filename"
      mysql-test/include/master-slave.inc:
        Remove old syntax "@filename" in favor of "--require filename"
      mysql-test/include/ps_query.inc:
        Remove the comment about no output now when it does.
      mysql-test/r/check.result:
        Update output from --send
      mysql-test/r/connect.result:
        Update result file for connect test after backport form 5.1
      mysql-test/r/flush.result:
        Update output from --send
      mysql-test/r/flush_block_commit.result:
        Update output from --send
      mysql-test/r/func_misc.result:
        Update output from --send
      mysql-test/r/grant2.result:
        Update output from --send
      mysql-test/r/handler.result:
        Update output from --send
      mysql-test/r/kill.result:
        Update output from --send
      mysql-test/r/lock_multi.result:
        Update output from --send
      mysql-test/r/mix_innodb_myisam_binlog.result:
        Update output from --send
      mysql-test/r/mysqltest.result:
        Update mysqltest.result after backport
      mysql-test/r/ps_2myisam.result:
        Update result as the output from query is now printed
      mysql-test/r/ps_3innodb.result:
        Update result as the output from query is now printed
      mysql-test/r/ps_4heap.result:
        Update result as the output from query is now printed
      mysql-test/r/ps_5merge.result:
        Update result as the output from query is now printed
      mysql-test/r/ps_6bdb.result:
        Update result as the output from query is now printed
      mysql-test/r/ps_7ndb.result:
        Update result as the output from query is now printed
      mysql-test/r/rename.result:
        Update output from --send
      mysql-test/r/rpl000001.result:
        Update output from --send
      mysql-test/r/rpl_error_ignored_table.result:
        Update output from --send
      mysql-test/r/rpl_master_pos_wait.result:
        Update output from --send
      mysql-test/r/subselect.result:
        Update result file after adding missing ;
      mysql-test/r/synchronization.result:
        Update output from --send
      mysql-test/r/type_blob.result:
        Update result file after adding missing ;
      mysql-test/t/connect.test:
        Backport test from 5.1
      mysql-test/t/init_file.test:
        Update test so something is printed
      mysql-test/t/mysql_client_test.test:
        Update test so result is sent to file and something is printed
      mysql-test/t/mysqltest.test:
        Backport latest mysqltest.test file
      mysql-test/t/ps.test:
        Move the --replace_column statement to just before the statetement it should replace
      mysql-test/t/ps_1general.test:
        Move the --replace_column statement to just before the statetement it should replace
      mysql-test/t/ps_grant.test:
        Remove the $DB, no other test uses it
      mysql-test/t/rpl_flush_tables.test:
        Fetch $SERVER_VERSION from the db server
      mysql-test/t/rpl_trunc_temp.test:
        Remove the selection of connection master after it's been disconnected already
      mysql-test/t/subselect.test:
        Add missing ;
      mysql-test/t/type_blob.test:
        Add missing ;
      9368c7bc
  24. 27 Sep, 2006 1 commit
    • unknown's avatar
      BUG#21081: SELECT inside stored procedure returns wrong results · 7efdc62f
      unknown authored
      Re-execution of a parametrized prepared statement or a stored routine
      with a SELECT that use LEFT JOIN with second table having only one row
      could yield incorrect result.
      
      The problem appeared only for left joins with second table having only
      one row (aka const table) and equation conditions in ON or WHERE clauses
      that depend on the argument passed.  Once the condition was false for
      second const table, a NULL row was created for it, and any field involved
      got NULL-value flag, which then was never reset.
      
      The cause of the problem was that Item_field::null_value could be set
      without being reset for re-execution.  The solution is to reset
      Item_field::null_value in Item_field::cleanup().
      
      
      mysql-test/r/ps.result:
        Add result for bug#21081: SELECT inside stored procedure returns wrong
        results.
      mysql-test/t/ps.test:
        Add test case for bug#21081: SELECT inside stored procedure returns wrong
        results.
      sql/item.cc:
        Reset Item_field::null_value flag for re-execution.
      7efdc62f
  25. 19 Sep, 2006 1 commit
  26. 16 Sep, 2006 1 commit
    • unknown's avatar
      Fixed bug #22085: Crash on the execution of a prepared · c46151d9
      unknown authored
      statement that uses an aggregating IN subquery with 
      HAVING clause.
      A wrong order of the call of split_sum_func2 for the HAVING
      clause of the subquery and the transformation for the 
      subquery resulted in the creation of a andor structure
      that could not be restored at an execution of the prepared
      statement.
      
      
      mysql-test/r/ps.result:
        Added a test cases for bug #22085.
      mysql-test/t/ps.test:
        Added a test cases for bug #22085.
      c46151d9
  27. 24 Aug, 2006 1 commit
    • unknown's avatar
      BUG#21166: Prepared statement causes signal 11 on second execution · 965a3970
      unknown authored
      Changes in an item tree done by optimizer weren't properly
      registered and went unnoticed, which resulted in preliminary freeing
      of used memory.
      
      
      mysql-test/r/ps.result:
        Add result for bug#21166: Prepared statement causes signal 11
        on second execution.
      mysql-test/t/ps.test:
        Add test case for bug#21166: Prepared statement causes signal 11
        on second execution.
      sql/item.cc:
        Move Item::transform() and Item_default_value::transform() from
        item.h here and use THD::change_item_tree() instead of plain
        assignment.
        Change Item_field::set_no_const_sub() to be used with Item::walk()
        instead of Item::transform().
      sql/item.h:
        Move definition of Item::transform() and Item_default_value::transform()
        to item.cc.
        Change Item::set_no_const_sub() to be used with Item::walk()
        instead of Item::transform().
      sql/item_cmpfunc.cc:
        Use Item::walk() to execute Item::set_no_const_sub().
        Use THD::change_item_tree() instead of plain assignment.
      sql/item_func.cc:
        Add assert and comment to Item_func::traverse_cond().
      sql/item_row.cc:
        Use THD::change_item_tree() instead of plain assignment.
      sql/item_strfunc.cc:
        Move Item_func_make_set::transform() from item_strfunc.h here and use
        THD::change_item_tree() instead of plain assignment.
      sql/item_strfunc.h:
        Move definition of Item_func_make_set::transform() to item_strfunc.cc.
      965a3970
  28. 11 Jul, 2006 1 commit
    • unknown's avatar
      Post-merge fixes for Bug#19399 "Stored Procedures 'Lost Connection' · 3ff08ab8
      unknown authored
      when dropping/creating tables"
      
      
      mysql-test/r/ps.result:
        A post-merge fix.
      mysql-test/t/ps.test:
        A post-merge fix: all 5.0 tests should go after 4.1 tests.
      sql/sql_lex.cc:
        auxilliary -> auxiliary
      sql/sql_prepare.cc:
        auxilliary -> auxiliary
      sql/table.cc:
        Update st_table_list::reinit_before_use in 5.0 to include 5.0-specific
        cleanups.
      sql/table.h:
        st_table_list::reinit_before_use is public.
      3ff08ab8
  29. 06 Jul, 2006 1 commit
    • unknown's avatar
      A fix and a test case for Bug#19399 "res 'Lost Connection' when · 8995277a
      unknown authored
      dropping/creating tables".
      
      The bug could lead to a crash when multi-delete statements were
      prepared and used with temporary tables.
      
      The bug was caused by lack of clean-up of multi-delete tables before
      re-execution of a prepared statement. In a statement like
      DELETE t1 FROM t1, t2 WHERE ... the first table list (t1) is
      moved to lex->auxilliary_table_list and excluded from lex->query_tables
      or select_lex->tables. Thus it was unaccessible to reinit_stmt_before_use
      and not cleaned up before re-execution of a prepared statement. 
      
      
      mysql-test/r/ps.result:
        Updated test results (Bug#19399)
      mysql-test/t/ps.test:
        A test case for Bug#19399 "Stored Procedures 'Lost Connection' when 
        dropping/creating tables": test that multi-delete
        tables are cleaned up properly before re-execution.
      sql/sql_lex.cc:
        Always initialize auxilliary_table_list when we initialize the lex:
        this way we don't have to check that lex->sql_command equals to
        SQLCOM_DELETE_MULTI whenever we need to access auxilliary_table_list.
        In particular, in reinit_stmt_before_use we can simply check that
        auxilliary_table_list is not NULL and clean it up if the check returns
        a true value.
      sql/sql_prepare.cc:
        Move the one table clean-up functionality to a method of st_table_list.
        Clean up auxiliary_table_list if it's not empty.
      sql/table.cc:
        Implement st_table_list::reinit_before_use().
      sql/table.h:
        Declare st_table_list::reinit_before_use().
      8995277a
  30. 26 Jun, 2006 1 commit
    • unknown's avatar
      A fix and a test case for · d6bcbfbe
      unknown authored
       Bug#19022 "Memory bug when switching db during trigger execution"
       Bug#17199 "Problem when view calls function from another database."
       Bug#18444 "Fully qualified stored function names don't work correctly in
                  SELECT statements"
      
       Documentation note: this patch introduces a change in behaviour of prepared
       statements.
      
       This patch adds a few new invariants with regard to how THD::db should
       be used. These invariants should be preserved in future:
      
        - one should never refer to THD::db by pointer and always make a deep copy
          (strmake, strdup)
        - one should never compare two databases by pointer, but use strncmp or
          my_strncasecmp
        - TABLE_LIST object table->db should be always initialized in the parser or
          by creator of the object.
      
          For prepared statements it means that if the current database is changed
          after a statement is prepared, the database that was current at prepare
          remains active. This also means that you can not prepare a statement that
          implicitly refers to the current database if the latter is not set.
          This is not documented, and therefore needs documentation. This is NOT a
          change in behavior for almost all SQL statements except:
           - ALTER TABLE t1 RENAME t2 
           - OPTIMIZE TABLE t1
           - ANALYZE TABLE t1
           - TRUNCATE TABLE t1 --
           until this patch t1 or t2 could be evaluated at the first execution of
           prepared statement. 
      
           CURRENT_DATABASE() still works OK and is evaluated at every execution
           of prepared statement.
      
           Note, that in stored routines this is not an issue as the default
           database is the database of the stored procedure and "use" statement
           is prohibited in stored routines.
      
        This patch makes obsolete the use of check_db_used (it was never used in the
        old code too) and all other places that check for table->db and assign it
        from THD::db if it's NULL, except the parser.
      
       How this patch was created: THD::{db,db_length} were replaced with a
       LEX_STRING, THD::db. All the places that refer to THD::{db,db_length} were
       manually checked and:
        - if the place uses thd->db by pointer, it was fixed to make a deep copy
        - if a place compared two db pointers, it was fixed to compare them by value
          (via strcmp/my_strcasecmp, whatever was approproate)
       Then this intermediate patch was used to write a smaller patch that does the
       same thing but without a rename.
      
       TODO in 5.1:
         - remove check_db_used
         - deploy THD::set_db in mysql_change_db
      
       See also comments to individual files.
      
      
      mysql-test/r/create.result:
        Modify the result file: a database can never be NULL.
      mysql-test/r/ps.result:
        Update test results (Bug#17199 et al)
      mysql-test/r/sp.result:
        Update test results (Bug#17199 et al)
      mysql-test/t/create.test:
        Update the id of the returned error.
      mysql-test/t/ps.test:
        Add test coverage for prepared statements and current database. In scope of
        work on Bug#17199 "Problem when view calls function from another database."
      mysql-test/t/sp.test:
        Add a test case for Bug#17199 "Problem when view calls function from another
        database." and Bug#18444 "Fully qualified stored function names don't work
        correctly in SELECT statements". Test a complementary problem.
      sql/item_strfunc.cc:
        Touch the code that reads thd->db (cleanup).
      sql/log_event.cc:
        While we are at it, replace direct access to thd->db with a method.
        Should simplify future conversion of THD::db to LEX_STRING.
      sql/slave.cc:
        While we are at it, replace direct access to thd->db with a method.
        Should simplify future conversion of THD::db to LEX_STRING.
      sql/slave.h:
        Remove a declaration for a method that is used only in one module.
      sql/sp.cc:
        Rewrite sp_use_new_db: this is a cleanup that I needed in order to understand
        this function and ensure that it has no bugs.
      sql/sp.h:
        Add a new declaration for sp_use_new_db (uses LEX_STRINGs) and a comment.
      sql/sp_head.cc:
        - drop sp_name_current_db_new - a creator of sp_name class that was used
        when sp_name was created for an identifier without an explicitly initialized
        database. Now we pass thd->db to constructor of sp_name right in the 
        parser.
        - rewrite sp_head::init_strings: name->m_db is always set now
        - use the new variant of sp_use_new_db
        - we don't need to update thd->db with SP MEM_ROOT pointer anymore when
        parsing a stored procedure, as noone will refer to it (yes!)
      sql/sp_head.h:
        - remove unneded methods and members
      sql/sql_class.h:
        - introduce 3 THD  methods to work with THD::db:
          .set_db to assign the current database
          .reset_db to reset the current database (temporarily) or set it to NULL
          .opt_copy_db_to - to deep-copy thd->db to a pointer if it's not NULL
      sql/sql_db.cc:
        While we are at it, replace direct access to thd->db with a method.
        Should simplify future conversion of THD::db to LEX_STRING.
      sql/sql_insert.cc:
        - replace checks with asserts: table_list->db must be always set in the parser.
      sql/sql_lex.h:
        - add a comment
      sql/sql_parse.cc:
        - implement the invariant described in the changeset comment.
        - remove juggling with lex->sphead in SQLCOM_CREATE_PROCEDURE:
          now db_load_routine uses its own LEX object and doesn't damage the main
          LEX.
        - add DBUG_ASSERT(0) to unused "check_db_used"
      sql/sql_table.cc:
        - replace a check with an assert (table_ident->db)
      sql/sql_trigger.cc:
        While we are at it, replace direct access to thd->db with a method.
        Should simplify future conversion of THD::db to LEX_STRING.
      sql/sql_udf.cc:
        - use thd->set_db instead of direct modification of to thd->db
      sql/sql_view.cc:
        - replace a check with an assert (view->db)
      sql/sql_yacc.yy:
        - make sure that we always copy table->db or name->db or ident->db or
          select_lex->db from thd->db if the former is not set. If thd->db
          is not set but is accessed, return an error.
      sql/tztime.cc:
        - be nice, never copy thd->db by pointer.
      d6bcbfbe
  31. 29 May, 2006 1 commit
  32. 25 Apr, 2006 1 commit
    • unknown's avatar
      A fix and a test case for Bug#19308 "REPAIR/OPTIMIZE/ANALYZE · f28b9a34
      unknown authored
      supported in SP but not in PS": just enable them in prepared
      statements, the supporting functionality was implemented when
      they were enabled in stored procedures.
      
      
      mysql-test/r/ps.result:
        Bug#19308: test results fixed.
      mysql-test/r/ps_1general.result:
        Adjust existing test cases (ANALYZE/OPTIMIZE/REPAIR are now
        allowed in prepared statements.
      mysql-test/r/sp-dynamic.result:
        Adjust existing test cases (ANALYZE/OPTIMIZE/REPAIR are now
        allowed in prepared statements.
      mysql-test/t/ps.test:
        Add a test case for Bug#19308 "REPAIR/OPTIMIZE/ANALYZE supported 
        in SP but not in PS"
      mysql-test/t/ps_1general.test:
        Adjust existing test cases (ANALYZE/OPTIMIZE/REPAIR are now
        allowed in prepared statements.
      sql/sql_prepare.cc:
        Enable ANALYZE, OPTIMIZE, REPAIR in prepared statements.
      f28b9a34
  33. 12 Apr, 2006 1 commit
    • unknown's avatar
      Post-merge fixes. Add a new error message for max_prepared_stmt_count · c5ed5c4b
      unknown authored
      limit.
      
      
      mysql-test/r/ps.result:
        Post-merge fixes.
      mysql-test/t/ps.test:
        Post-merge fixes.
      sql/share/errmsg.txt:
        Add a new error message for max_prepared_stmt_count limit,
        we can do it in 5.0
      sql/sql_class.cc:
        Post-merge fixes.
      sql/sql_class.h:
        Post-merge fixes.
      sql/sql_prepare.cc:
        Post-merge fixes.
      c5ed5c4b
  34. 07 Apr, 2006 2 commits
    • unknown's avatar
      A fix and a test case for Bug#16365 "Prepared Statements: DoS with · 5b5530da
      unknown authored
      too many open statements". The patch adds a new global variable
      @@max_prepared_stmt_count. This variable limits the total number
      of prepared statements in the server. The default value of
      @@max_prepared_stmt_count is 16382. 16382 small statements
      (a select against 3 tables with GROUP, ORDER and LIMIT) consume 
      100MB of RAM. Once this limit has been reached, the server will 
      refuse to prepare a new statement and return ER_UNKNOWN_ERROR 
      (unfortunately, we can't add new errors to 4.1 without breaking 5.0). The limit is changeable after startup
      and can accept any value from 0 to 1 million. In case
      the new value of the limit is less than the current
      statement count, no new statements can be added, while the old
      still can be used. Additionally, the current count of prepared 
      statements is now available through a global read-only variable 
      @@prepared_stmt_count.
      
      
      mysql-test/r/ps.result:
        Test results fixed (a test case for Bug#16365)
      mysql-test/t/ps.test:
        A test case for Bug#16365 "Prepared Statements: DoS with too many 
        open statements". Also fix statement leaks in other tests.
      sql/mysql_priv.h:
        Add declarations for new global variables.
      sql/mysqld.cc:
        Add definitions of max_prepared_stmt_count, prepared_stmt_count.
      sql/set_var.cc:
        Implement support for @@prepared_stmt_count and 
        @@max_prepared_stmt_count. Currently these variables are queried
        without acquiring LOCK_prepared_stmt_count due to limitations of
        the set_var/sys_var class design. Updates are, however, protected 
        with a lock.
      sql/set_var.h:
        New declarations to add support for @@max_prepared_stmt_count.
        Implement a new class, where the lock to be used when updating
        a variable is a parameter.
      sql/sql_class.cc:
        Add accounting of the total number of prepared statements in the
        server to the methods of Statement_map.
      sql/sql_class.h:
        Add accounting of the total number of prepared statements in the
        server to the methods of Statement_map.
      sql/sql_prepare.cc:
        Statement_map::insert will now send a message in case of an
        error.
      5b5530da
    • unknown's avatar
      A fix and a test case for Bug#16248 "WHERE (col1,col2) IN ((?,?)) · 9b6e83f4
      unknown authored
      gives wrong results". Implement previously missing 
      Item_row::cleanup. The bug is not repeatable in 5.0, probably 
      due to a coincidence: the problem is present in 5.0 as well.
      
      
      mysql-test/r/ps.result:
        Update the result file (Bug#16248)
      mysql-test/t/ps.test:
        Add a test case for Bug#16248 "WHERE (col1,col2) IN ((?,?)) gives 
        wrong results"
      sql/item_row.cc:
        Implement Item_row::cleanup(): we should reset used_tables_cache
        before reexecution of a prepared statement. In case ROW
        arguments contain a placeholder, used_tables_cache has PARAM_TABLE
        bit set in statement prepare. As a result, when executing a statement,
        the condition push down algorithm (make_cond_for_table) would think
        that the WHERE clause belongs to the non-existent PARAM_TABLE and
        wouldn't attach the WHERE clause to any of the real tables, 
        effectively optimizing the clause away.
      sql/item_row.h:
        Remove a never used member 'array_holder'. Add declaration for
        Item_row::cleanup.
      9b6e83f4
  35. 28 Mar, 2006 1 commit
    • unknown's avatar
      Post review fixes for BUG#16474: SP crashed MySQL. · 537ec1e6
      unknown authored
      mysql-test/r/ps.result:
        Added test coverage for "order by" in prepared statements (related to BUG#16474).
      mysql-test/r/sp.result:
        Added reference to test case for BUG#16474.
      mysql-test/t/ps.test:
        Added test coverage for "order by" in prepared statements (related to BUG#16474).
      mysql-test/t/sp.test:
        Added reference to test case for BUG#16474.
      sql/sql_select.cc:
        Fixed comment and test for basic_const_item() instead of is_splocal().
      537ec1e6
  36. 23 Feb, 2006 1 commit
    • unknown's avatar
      Remove 'delayed' to make the test deterministic (already · ea9ea952
      unknown authored
      fixed in 5.0).
      A post-review fix (Bug#13134)
      
      
      mysql-test/r/heap.result:
        Remove 'delayed' to make the test deterministic.
      mysql-test/r/ps.result:
        Remove an unneeded drop table (test case for Bug#13134)
      mysql-test/t/heap.test:
        Remove 'delayed' to make the test deterministic.
      mysql-test/t/ps.test:
        A post-review fix (Bug#13134)
      ea9ea952
  37. 21 Feb, 2006 1 commit
    • unknown's avatar
      A fix and a test case for Bug#13134 "Length of VARCHAR() utf8 · 9cf3f255
      unknown authored
      column is increasing when table is recreated with PS/SP":
      make use of create_field::char_length more consistent in the code.
      Reinit create_field::length from create_field::char_length
      for every execution of a prepared statement (actually fixes the 
      bug).
      
      
      mysql-test/r/ps.result:
        Test results fixed (Bug#13134)
      mysql-test/t/ps.test:
        A test case for Bug#13134 "Length of VARCHAR() utf8 column is 
        increasing when table is recreated with PS/SP"
      sql/field.cc:
        Move initialization of create_field::char_length to the constructor
        of create_field.
      sql/field.h:
        Rename chars_length to char_length (to be consistent with
        how this term is used throughout the rest of the code).
      sql/sql_parse.cc:
        Initialize char_length in add_field_to_list. This function
        effectively works as another create_field constructor.
      sql/sql_table.cc:
        Reinit length from char_length for every field in 
        mysql_prepare_table. This is not needed if we're executing
        a statement for the first time, however, at subsequent executions
        length contains the number of bytes, not characters (as it's expected 
        to).
      9cf3f255