An error occurred fetching the project authors.
  1. 04 Oct, 2007 1 commit
  2. 28 Sep, 2007 2 commits
  3. 20 Sep, 2007 1 commit
  4. 21 Aug, 2007 1 commit
  5. 20 Aug, 2007 1 commit
  6. 09 Aug, 2007 1 commit
  7. 02 Aug, 2007 1 commit
  8. 11 Jul, 2007 1 commit
  9. 28 Jun, 2007 1 commit
    • anozdrin/alik@ibm.'s avatar
      Patch for the following bugs: · 9fae9ef6
      anozdrin/alik@ibm. authored
        - BUG#11986: Stored routines and triggers can fail if the code
          has a non-ascii symbol
        - BUG#16291: mysqldump corrupts string-constants with non-ascii-chars
        - BUG#19443: INFORMATION_SCHEMA does not support charsets properly
        - BUG#21249: Character set of SP-var can be ignored
        - BUG#25212: Character set of string constant is ignored (stored routines)
        - BUG#25221: Character set of string constant is ignored (triggers)
      
      There were a few general problems that caused these bugs:
      1. Character set information of the original (definition) query for views,
         triggers, stored routines and events was lost.
      2. mysqldump output query in client character set, which can be
         inappropriate to encode definition-query.
      3. INFORMATION_SCHEMA used strings with mixed encodings to display object
         definition;
      
      1. No query-definition-character set.
      
      In order to compile query into execution code, some extra data (such as
      environment variables or the database character set) is used. The problem
      here was that this context was not preserved. So, on the next load it can
      differ from the original one, thus the result will be different.
      
      The context contains the following data:
        - client character set;
        - connection collation (character set and collation);
        - collation of the owner database;
      
      The fix is to store this context and use it each time we parse (compile)
      and execute the object (stored routine, trigger, ...).
      
      2. Wrong mysqldump-output.
      
      The original query can contain several encodings (by means of character set
      introducers). The problem here was that we tried to convert original query
      to the mysqldump-client character set.
      
      Moreover, we stored queries in different character sets for different
      objects (views, for one, used UTF8, triggers used original character set).
      
      The solution is
        - to store definition queries in the original character set;
        - to change SHOW CREATE statement to output definition query in the
          binary character set (i.e. without any conversion);
        - introduce SHOW CREATE TRIGGER statement;
        - to dump special statements to switch the context to the original one
          before dumping and restore it afterwards.
      
      Note, in order to preserve the database collation at the creation time,
      additional ALTER DATABASE might be used (to temporary switch the database
      collation back to the original value). In this case, ALTER DATABASE
      privilege will be required. This is a backward-incompatible change.
      
      3. INFORMATION_SCHEMA showed non-UTF8 strings
      
      The fix is to generate UTF8-query during the parsing, store it in the object
      and show it in the INFORMATION_SCHEMA.
      
      Basically, the idea is to create a copy of the original query convert it to
      UTF8. Character set introducers are removed and all text literals are
      converted to UTF8.
      
      This UTF8 query is intended to provide user-readable output. It must not be
      used to recreate the object.  Specialized SHOW CREATE statements should be
      used for this.
      
      The reason for this limitation is the following: the original query can
      contain symbols from several character sets (by means of character set
      introducers).
      
      Example:
      
        - original query:
          CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1;
      
        - UTF8 query (for INFORMATION_SCHEMA):
          CREATE VIEW v1 AS SELECT 'Hello' AS c1;
      9fae9ef6
  10. 09 Jun, 2007 2 commits
  11. 29 May, 2007 1 commit
  12. 15 May, 2007 1 commit
  13. 04 May, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      bug #27531: 5.1 part of the fix: · 306371a8
      gkodinov/kgeorge@magare.gmz authored
       - added join cache indication in EXPLAIN (Extra column).
       - prefer filesort over full scan over 
         index for ORDER BY (because it's faster).
       - when switching from REF to RANGE because
         RANGE uses longer key turn off sort on
         the head table only as the resulting 
         RANGE access is a candidate for join cache
         and we don't want to disable it by sorting
         on the first table only. 
      306371a8
  14. 05 Apr, 2007 1 commit
  15. 04 Apr, 2007 1 commit
  16. 03 Apr, 2007 1 commit
  17. 02 Apr, 2007 1 commit
  18. 27 Mar, 2007 1 commit
  19. 13 Feb, 2007 1 commit
  20. 12 Feb, 2007 1 commit
    • gluh@mysql.com/eagle.(none)'s avatar
      Bug#24630 Subselect query crashes mysqld · 47e537b4
      gluh@mysql.com/eagle.(none) authored
      The crash happens because second filling of the same I_S table happens in
      case of subselect with order by. table->sort.io_cache previously allocated
      in create_sort_index() is deleted during second filling
      (function get_schema_tables_result). There are two places where
      I_S table can be filled: JOIN::exec and create_sort_index().
      To fix the bug we should check if the table was already filled
      in one of these places and skip processing of the table in second.
      47e537b4
  21. 11 Feb, 2007 1 commit
    • evgen@moonbone.local's avatar
      sql_view.cc: · ffdf7b15
      evgen@moonbone.local authored
        Post fix for bug#12122.
      information_schema.result:
        Corrected test case after fixing bug#12122.
      ffdf7b15
  22. 01 Feb, 2007 1 commit
  23. 09 Dec, 2006 1 commit
    • patg@govinda.patg.net's avatar
      WL# 3031 · 98062f56
      patg@govinda.patg.net authored
      Post-commit issues fixed
      * Test results for other tests fixed due to added error #s
      * Memory allocation/free issues found with running with valgrind
      * Fix to mysql-test-run shell script to run federated_server test (installs
      mysql.servers table properly)
      98062f56
  24. 01 Dec, 2006 2 commits
  25. 21 Nov, 2006 3 commits
  26. 23 Oct, 2006 2 commits
  27. 13 Sep, 2006 1 commit
  28. 06 Sep, 2006 1 commit
  29. 15 Aug, 2006 1 commit
  30. 01 Aug, 2006 1 commit
  31. 25 Jul, 2006 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #21231: wrong results for a simple query with a · 69856b29
      igor@olga.mysql.com authored
      a non-correlated single-row subquery over information schema.
      
      The function get_all_tables filling all information schema
      tables reset lex->sql_command to SQLCOM_SHOW_FIELDS. After
      this the function could evaluate partial conditions related to
      some columns. If these conditions contained a subquery over
      information schema it led to a wrong evaluation and a wrong 
      result set.
      This bug was already fixed in 5.1.
      This patch follows the way how it was done in 5.1 where
      the value of lex->sql_command is set to SQLCOM_SHOW_FIELDS
      in get_all_tables only for the calls of the function 
      open_normal_and_derived_tables and is restored after these
      calls.
      69856b29
  32. 22 Jul, 2006 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #18925: wrong results for queries with · 66ecb7df
      igor@olga.mysql.com authored
      subqueries on information schema that use MIN/MAX aggregation.
      
      Execution of some correlated subqueries may set the value
      of null_row to 1 for tables used in the subquery.
      If the the subquery is on information schema it causes
      rejection of any row for the following executions of
      the subquery in the case when an optimization filtering
      by some condition is applied.
      
      The fix restores the value of the null_row flag for 
      each execution of a subquery on information schema.
      66ecb7df
  33. 14 Jul, 2006 1 commit
  34. 29 Jun, 2006 1 commit