1. 13 Nov, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #31562: HAVING and lower case · 3384d3e9
      gkodinov/kgeorge@magare.gmz authored
      The columns in HAVING can reference the GROUP BY and 
      SELECT columns. There can be "table" prefixes when
      referencing these columns. And these "table" prefixes
      in HAVING use the table alias if available.
      This means that table aliases are subject to the same
      storage rules as table names and are dependent on 
      lower_case_table_names in the same way as the table 
      names are.
      Fixed by :
      1. Treating table aliases as table names
      and make them lowercase when printing out the SQL
      statement for view persistence.
      2. Using case insensitive comparison for table 
      aliases when requested by lower_case_table_names
      3384d3e9
  2. 08 Nov, 2007 4 commits
  3. 07 Nov, 2007 1 commit
    • kaa@polly.(none)'s avatar
      Fix for bug #32103: optimizer crash when join on int and mediumint with · f1a3c364
      kaa@polly.(none) authored
      variable in where clause.
      
      Problem: the new_item() method of Item_uint used an incorrect
      constructor. "new Item_uint(name, max_length)" calls
      Item_uint::Item_uint(const char *str_arg, uint length) which assumes the
      first argument to be the string representation of the value, not the
      item's name. This could result in either a server crash or incorrect
      results depending on usage scenarios.
      
      Fixed by using the correct constructor in new_item():
      Item_uint::Item_uint(const char *str_arg, longlong i, uint length).
      f1a3c364
  4. 05 Nov, 2007 5 commits
  5. 02 Nov, 2007 2 commits
    • kaa@polly.(none)'s avatar
      Merge polly.(none):/home/kaa/src/opt/bug26215/my50-bug26215 · fa462599
      kaa@polly.(none) authored
      into  polly.(none):/home/kaa/src/opt/mysql-5.0-opt
      fa462599
    • kaa@polly.(none)'s avatar
      Fix for: · 9cd5f49c
      kaa@polly.(none) authored
        bug #26215: mysql command line client should not strip comments
                    from SQL statements
      and
        bug #11230: Keeping comments when storing stored procedures
      
      With the introduction of multiline comments support in the command line
      client (mysql) in MySQL 4.1, it became impossible to preserve
      client-side comments within single SQL statements or stored routines.
      This feature was useful for monitoring tools and maintenance.
      
      The patch adds a new option to the command line client
      ('--enable-comments', '-c') which allows to preserve SQL comments and
      send them to the server for single SQL statements, and to keep comments
      in the code for stored procedures / functions / triggers.
      
      The patch is a modification of the contributed patch from bug #11230
      with the following changes:
      - code style changes to conform to the coding guidelines
      - changed is_prefix() to my_strnncoll() to detect the DELIMITER
      command, since the first one is case-sensitive and not charset-aware
      - renamed t/comments-51.* to t/mysql_comments.*
      - removed tests for comments in triggers since 5.0 does not have SHOW
      CREATE TRIGGER (those tests will be added back in 5.1).
      
      The test cases are only for bug #11230. No automated test case for bug
      #26215 is possible due to the test suite deficiencies (though the cases
      from the bug report were tested manually).
      9cd5f49c
  6. 01 Nov, 2007 1 commit
  7. 30 Oct, 2007 3 commits
  8. 29 Oct, 2007 5 commits
  9. 27 Oct, 2007 2 commits
  10. 26 Oct, 2007 3 commits
  11. 25 Oct, 2007 2 commits
    • kaa@polly.(none)'s avatar
      Fix for bug #29131: SHOW VARIABLES reports variable 'log' but SET · 99f4b743
      kaa@polly.(none) authored
      doesn't recognize it
      
      This is a 5.0 version of the patch, it will be null-merged to 5.1
      
      Problem:
      
      'log' and 'log_slow_queries' were "fixed" variables, i.e. they showed up
      in SHOW VARIABLES, but could not be used in expressions like 
      "select @@log". Also, using them in the SET statement produced an 
      incorrect "unknown system variable" error.
      
      Solution:
      
      Make 'log' and 'log_slow_queries' read-only dynamic variables to make 
      them available for use in expressions, and produce a correct error 
      about the variable being read-only when used in the SET statement.
      99f4b743
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #27695: View should not be allowed to have empty or · e36846de
      gshchepa/uchum@gleb.loc authored
      all space column names.
      
      The parser has been modified to check VIEW column names
      with the check_column_name function and to report an error
      on empty and all space column names (same as for TABLE
      column names).
      e36846de
  12. 24 Oct, 2007 2 commits
    • gkodinov/kgeorge@magare.gmz's avatar
      Merge magare.gmz:/home/kgeorge/mysql/work/B30715-5.0-opt · 1cda34d3
      gkodinov/kgeorge@magare.gmz authored
      into  magare.gmz:/home/kgeorge/mysql/work/B30715-merged-5.0-opt
      1cda34d3
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #30715: Assertion failed: item_field->field->real_maybe_null(), · 54cea400
      gkodinov/kgeorge@magare.gmz authored
        file .\opt_sum.cc, line
      The optimizer pre-calculates the MIN/MAX values for queries like
       SELECT MIN(kp_k) WHERE kp_1 = const AND ... AND kp_k-1 = const
      when there is a key over kp_1...kp_k
      In doing so it was not checking correctly nullability and 
      there was a superfluous assert(). 
      Fixed by making sure that the field can be null before checking and
      taking out the wrong assert().
      .
      Introduced a correct check for nullability 
      The MIN(field) can return NULL when all the row values in the group
      are NULL-able or if there were no rows.
      Fixed the assertion to reflect the case when there are no rows.
      54cea400
  13. 23 Oct, 2007 9 commits