An error occurred fetching the project authors.
  1. 11 Dec, 2006 1 commit
  2. 07 Dec, 2006 1 commit
    • kostja@bodhi.local's avatar
      A fix and test cases for · 90072e69
      kostja@bodhi.local 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).
      90072e69
  3. 01 Nov, 2006 1 commit
  4. 31 Oct, 2006 1 commit
    • sergefp@mysql.com's avatar
      BUG#8804: wrong results for NULL IN (SELECT ...) · 54a713aa
      sergefp@mysql.com authored
      Evaluate "NULL IN (SELECT ...)" in a special way: Disable pushed-down 
      conditions and their "consequences": 
       = Do full table scans instead of unique_[index_subquery] lookups.
       = Change appropriate "ref_or_null" accesses to full table scans in
         subquery's joins.
      Also cache value of NULL IN (SELECT ...) if the SELECT is not correlated 
      wrt any upper select.
      54a713aa
  5. 24 Oct, 2006 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      Bug #21809: Error 1356 while selecting from view with grouping though underlying · 932d86bb
      gkodinov/kgeorge@macbook.gmz authored
                  select OK.
      The SQL parser was using Item::name to transfer user defined function attributes
      to the user defined function (udf). It was not distinguishing between user defined 
      function call arguments and stored procedure call arguments. Setting Item::name 
      was causing Item_ref::print() method to print the argument as quoted identifiers 
      and caused views that reference aggregate functions as udf call arguments (and 
      rely on Item::print() for the text of the view to store) to throw an undefined 
      identifier error.
      Overloaded Item_ref::print to print aggregate functions as such when printing
      the references to aggregate functions taken out of context by split_sum_func2()
      Fixed the parser to properly detect using AS clause in stored procedure arguments
      as an error.
      Fixed printing the arguments of udf call to print properly the udf attribute.
      932d86bb
  6. 16 Oct, 2006 1 commit
    • igor@rurik.mysql.com's avatar
      Fixed bug #19579: at range analysis optimizer did not take into · c467be8d
      igor@rurik.mysql.com authored
      account predicates that become sargable after reading const tables.
      In some cases this resulted in choosing non-optimal execution plans.
      Now info of such potentially saragable predicates is saved in
      an array and after reading const tables we check whether this
      predicates has become saragable.
      c467be8d
  7. 12 Oct, 2006 2 commits
    • kroki/tomash@moonlight.intranet's avatar
      BUG#20953: create proc with a create view that uses local vars/params · 591c06d4
      kroki/tomash@moonlight.intranet authored
                 should fail to create
      
      The problem was that this type of errors was checked during view
      creation, which doesn't happen when CREATE VIEW is a statement of
      a created stored routine.
      
      The solution is to perform the checks at parse time.  The idea of the
      fix is that the parser checks if a construction just parsed is allowed
      in current circumstances by testing certain flags, and this flags are
      reset for VIEWs.
      
      The side effect of this change is that if the user already have
      such bogus routines, it will now get a error when trying to do
      
        SHOW CREATE PROCEDURE proc;
      
      (and some other) and when trying to execute such routine he will get
      
        ERROR 1457 (HY000): Failed to load routine test.p5. The table mysql.proc is missing, corrupt, or contains bad data (internal code -6)
      
      However there should be very few such users (if any), and they may
      (and should) drop these bogus routines.
      591c06d4
    • tsmith/tim@siva.hindu.god's avatar
  8. 04 Oct, 2006 1 commit
  9. 25 Sep, 2006 1 commit
    • igor@rurik.mysql.com's avatar
      Fixed bug #21646. · a661bdda
      igor@rurik.mysql.com authored
      Presence of a subquery in the ON expression of a join 
      should not block merging the view that contains this join.
      Before this patch the such views were converted into 
      into temporary table views.
      a661bdda
  10. 16 Sep, 2006 1 commit
    • igor@rurik.mysql.com's avatar
      Fixed bug #21493: crash for the second execution of a function · d3d3cef8
      igor@rurik.mysql.com authored
      containing a select statement that uses an aggregating IN subquery.
      Added a parameter to the function fix_prepare_information 
      to restore correctly the having clause for the second execution.
      Saved andor structure of the having conditions at the proper moment
      before any calls of split_sum_func2 that could modify the having structure
      adding new Item_ref objects. (These additions, are produced not with 
      the statement mem_root, but rather with the execution mem_root.)
      d3d3cef8
  11. 01 Sep, 2006 1 commit
  12. 23 Aug, 2006 1 commit
    • cmiller@maint1.mysql.com's avatar
      Bug #20908: Crash if select @@"" · 977e6966
      cmiller@maint1.mysql.com authored
      Zero-length variables caused failures when using the length to look
      up the name in a hash.  Instead, signal that no zero-length name can
      ever be found and that to encounter one is a syntax error.
      977e6966
  13. 15 Aug, 2006 2 commits
  14. 31 Jul, 2006 1 commit
  15. 27 Jul, 2006 1 commit
    • anozdrin/alik@booka.'s avatar
      Fix for BUG#20438: CREATE statements for views, stored routines and triggers · 2d082d86
      anozdrin/alik@booka. authored
      can be not replicable.
      
      Now CREATE statements for writing in the binlog are created as follows:
        - the beginning of the statement is re-created;
        - the rest of the statement is copied from the original query.
      
      The problem appears when there is a version-specific comment (produced by
      mysqldump), started in the re-created part of the statement and closed in the
      copied part -- there is closing comment-parenthesis, but there is no opening
      one.
      
      The proper fix could be to re-create original statement, but we can not
      implement it in 5.0. So, for 5.0 the fix is just to cut closing
      comment-parenthesis. This technique is also used for SHOW CREATE PROCEDURE
      statement (so we are able to reuse existing code).
      2d082d86
  16. 14 Jul, 2006 1 commit
  17. 11 Jul, 2006 1 commit
  18. 06 Jul, 2006 1 commit
    • konstantin@bodhi.netgear's avatar
      A fix and a test case for Bug#19399 "res 'Lost Connection' when · 8e735d2c
      konstantin@bodhi.netgear 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. 
      8e735d2c
  19. 30 Jun, 2006 1 commit
  20. 27 Jun, 2006 1 commit
  21. 30 May, 2006 1 commit
    • gluh@eagle.intranet.mysql.r18.ru's avatar
      Bug#17204 "second CALL to procedure crashes Server" · ae72df07
      gluh@eagle.intranet.mysql.r18.ru authored
      Bug#18282 "INFORMATION_SCHEMA.TABLES provides inconsistent info about invalid views"
      This bug caused crashes or resulted in wrong data being returned
      when one tried to obtain information from I_S tables about views
      using stored functions.
      
      It was caused by the fact that we were using LEX representing
      statement which were doing select from I_S tables as active LEX
      when contents of I_S table were built. So state of this LEX both
      affected and was affected by open_tables() calls which happened
      during this process. This resulted in wrong behavior and in
      violations of some of invariants which caused crashes.
      
      This fix tries to solve this problem by properly saving/resetting
      and restoring part of LEX which affects and is affected by the
      process of opening tables and views in get_all_tables() routine.
      To simplify things we separated this part of LEX in a new class
      and made LEX its descendant.
      ae72df07
  22. 23 May, 2006 2 commits
  23. 07 May, 2006 2 commits
    • igor@rurik.mysql.com's avatar
      Post-merge fixes. · b70efcac
      igor@rurik.mysql.com authored
      b70efcac
    • igor@rurik.mysql.com's avatar
      Fixed bug #14927. · 7977a0c8
      igor@rurik.mysql.com authored
      A query with a group by and having clauses could return a wrong
      result set if the having condition contained a constant conjunct 
      evaluated to FALSE.
      It happened because the pushdown condition for table with
      grouping columns lost its constant conjuncts.
      Pushdown conditions are always built by the function make_cond_for_table
      that ignores constant conjuncts. This is apparently not correct when
      constant false conjuncts are present.
      7977a0c8
  24. 04 May, 2006 1 commit
  25. 10 Mar, 2006 1 commit
  26. 09 Mar, 2006 2 commits
  27. 01 Feb, 2006 1 commit
    • igor@rurik.mysql.com's avatar
      FIxed bug #14927. · d6370b48
      igor@rurik.mysql.com authored
      A query with a group by and having clauses could return a wrong
      result set if the having condition contained a constant conjunct 
      evaluated to FALSE.
      It happened because the pushdown condition for table with
      grouping columns lost its constant conjuncts.
      Pushdown conditions are always built by the function make_cond_for_table
      that ignores constant conjuncts. This is apparently not correct when
      constant false conjuncts are present.
      d6370b48
  28. 28 Nov, 2005 1 commit
  29. 20 Nov, 2005 1 commit
    • bell@sanja.is.com.ua's avatar
      Inefficient usage of String::append() fixed. · 806f9e24
      bell@sanja.is.com.ua authored
      Bad examples of usage of a string with its length fixed.
      The incorrect length in the trigger file configuration descriptor
        fixed (BUG#14090).
      A hook for unknown keys added to the parser to support old .TRG files.
      806f9e24
  30. 02 Nov, 2005 1 commit
  31. 21 Oct, 2005 1 commit
  32. 15 Oct, 2005 1 commit
  33. 12 Oct, 2005 1 commit
  34. 09 Oct, 2005 1 commit
    • evgen@moonbone.local's avatar
      Fix bug#7672 Unknown column error in order clause · 6bfc2d4b
      evgen@moonbone.local authored
      When fixing Item_func_plus in ORDER BY clause field c is searched in all
      opened tables, but because c is an alias it wasn't found there.
      
      This patch adds a flag to select_lex which allows Item_field::fix_fields() 
      to look up in select's item_list to find aliased fields.
      6bfc2d4b
  35. 25 Sep, 2005 1 commit