1. 22 Jul, 2006 2 commits
  2. 21 Jul, 2006 6 commits
    • evgen@moonbone.local's avatar
      Merge epotemkin@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · 85405574
      evgen@moonbone.local authored
      into  moonbone.local:/work/autopush/12185-bug-5.0-opt-mysql
      85405574
    • evgen@moonbone.local's avatar
      Fixed bug#12185: Data type aggregation may produce wrong result · c875b8eb
      evgen@moonbone.local authored
      The Item::tmp_table_field_from_field_type() function creates Field_datetime
      object instead of Field_timestamp object for timestamp field thus always
      changing data type is a tmp table is used.
      
      The Field_blob object constructor which is used in the 
      Item::tmp_table_field_from_field_type() is always setting packlength field of
      newly created blob to 4. This leads to changing fields data type for example
      from the blob to the longblob if a temporary table is used.
      
      The Item::make_string_field() function always converts Field_string objects 
      to Field_varstring objects. This leads to changing data type from the 
      char/binary to varchar/varbinary.
      
      Added appropriate Field_timestamp object constructor for using in the 
      Item::tmp_table_field_from_field_type() function.
      
      Added Field_blob object constructor which sets pack length according to
      max_length argument.
      
      The Item::tmp_table_field_from_field_type() function now creates
      Field_timestamp object for a timestamp field.
      
      The Item_type_holder::display_length() now returns correct NULL length NULL
      length. 
      
      The Item::make_string_field() function now doesn't change Field_string to
      Field_varstring in the case of Item_type_holder. 
      
      The Item::tmp_table_field_from_field_type() function now uses the Field_blob
      constructor which sets packlength according to max_length.
      c875b8eb
    • gkodinov/kgeorge@rakia.(none)'s avatar
      Merge gkodinov@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · 98cd0a92
      gkodinov/kgeorge@rakia.(none) authored
      into  rakia.(none):/home/kgeorge/mysql/autopush/B20868-5.0-opt
      98cd0a92
    • gkodinov/kgeorge@macbook.gmz's avatar
      Bug #20868: Client connection is broken on SQL query error · 3ef086d2
      gkodinov/kgeorge@macbook.gmz authored
       An aggregate function reference was resolved incorrectly and
      caused a crash in count_field_types.
       Must use real_item() to get to the real Item instance through
      the reference
      3ef086d2
    • timour/tkatchaounov@lamia.home's avatar
      Merge tkatchaounov@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · bcf82284
      timour/tkatchaounov@lamia.home authored
      into  lamia.home:/home/tkatchaounov/autopush/5.0-bug-21007
      bcf82284
    • timour/timka@lamia.home's avatar
      Fix for BUG#21007. · 39ada211
      timour/timka@lamia.home authored
      The problem was that store_top_level_join_columns() incorrectly assumed
      that the left/right neighbor of a nested join table reference can be only
      at the same level in the join tree.
      
      The fix checks if the current nested join table reference has no immediate
      left/right neighbor, and if so chooses the left/right neighbors of the
      nearest upper level, where these references are != NULL.
      39ada211
  3. 19 Jul, 2006 3 commits
    • igor@olga.mysql.com's avatar
      8b7fc77a
    • igor@olga.mysql.com's avatar
      Merge olga.mysql.com:/home/igor/mysql-4.1-opt · d1c109ef
      igor@olga.mysql.com authored
      into  olga.mysql.com:/home/igor/mysql-5.0-opt
      d1c109ef
    • igor@olga.mysql.com's avatar
      Fixed bug #17526: incorrect print method · f201828d
      igor@olga.mysql.com authored
      for class Item_func_trim. 
      For 4.1 it caused wrong output for EXPLAIN EXTENDED commands
      if expressions with the TRIM function of two arguments were used.
      For 5.0 it caused an error message when trying to select
      from a view with the TRIM function of two arguments.
      This unexpected error message was due to the fact that the
      print method for the class Item_func_trim was inherited from
      the class Item_func. Yet the TRIM function does not take a list
      of its arguments. Rather it takes the arguments in the form:
        [{BOTH | LEADING | TRAILING} [remstr] FROM] str) |
        [remstr FROM] str
      f201828d
  4. 18 Jul, 2006 3 commits
  5. 17 Jul, 2006 5 commits
  6. 16 Jul, 2006 1 commit
  7. 15 Jul, 2006 5 commits
    • evgen@moonbone.local's avatar
      errmsg.txt: · 5431805c
      evgen@moonbone.local authored
        Fixed bug#10977: No warning issued if a column name is truncated
        New warning message is added.
      5431805c
    • evgen@moonbone.local's avatar
      Fixed bug#10977: No warning issued if a column name is truncated · f1346cf8
      evgen@moonbone.local authored
      When an alias is set to a column leading spaces are removed from the alias.
      But when this is done on aliases set by user this can lead to confusion.
      
      Now Item::set_name() method issues the warning if leading spaces were removed
      from an alias set by user.
      
      New warning message is added.
      f1346cf8
    • pekka@orca.ndb.mysql.com's avatar
      Merge orca.ndb.mysql.com:/space_old/pekka/ndb/version/my41-1.2461 · 14519de0
      pekka@orca.ndb.mysql.com authored
      into  orca.ndb.mysql.com:/space_old/pekka/ndb/version/my50
      14519de0
    • igor@rurik.mysql.com's avatar
      Fixed bug #20869. · 38cd55a7
      igor@rurik.mysql.com authored
      The bug caused a crash of the server if a subquery with
      ORDER BY DESC used the range access method.
      The bug happened because the method QUICK_SELECT_DESC::reset
      was not reworked after MRR interface had been introduced.
      38cd55a7
    • igor@olga.mysql.com's avatar
      Fixed bug #20519. · 4de3186a
      igor@olga.mysql.com authored
      The bug was due to a loss happened during a refactoring made
      on May 30 2005 that modified the function JOIN::reinit.
      As a result of it for any subquery the value of offset_limit_cnt
      was not restored for the following executions. Yet the first 
      execution of the subquery made it equal to 0.
      The fix restores this value in the function JOIN::reinit.  
      4de3186a
  8. 14 Jul, 2006 9 commits
  9. 13 Jul, 2006 6 commits