1. 30 May, 2007 6 commits
  2. 29 May, 2007 2 commits
    • evgen@moonbone.local's avatar
      Bug#28450: The Item_date_add_interval in select list may fail the field · 268fdf5d
      evgen@moonbone.local authored
      type assertion.
      
      The bug was introduced by the patch for bug #16377.
      The "+ INTERVAL" (Item_date_add_interval) function detects its result type
      by the type of its first argument. But in some cases it returns STRING
      as the result type. This happens when, for example, the first argument is a 
      DATE represented as string. All this makes the get_datetime_value()
      function misinterpret such result and return wrong DATE/DATETIME value.
      To avoid such cases in the fix for #16377 the code that detects correct result
      field type on the first execution was added to the
      Item_date_add_interval::get_date() function. Due to this the result
      field type of the Item_date_add_interval item stored by the send_fields()
      function differs from item's result field type at the moment when
      the item is actually sent. It causes an assertion failure.
      
      Now the get_datetime_value() detects that the DATE value is returned by
      some item not only by checking the result field type but also by comparing
      the returned value with the 100000000L constant - any DATE value should be
      less than this value.
      Removed result field type adjusting code from the
      Item_date_add_interval::get_date() function.
      268fdf5d
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #28605: SHOW CREATE VIEW with views using stored_procedures no · a6ebd634
      gkodinov/kgeorge@magare.gmz authored
       longer showing SP names.
      SHOW CREATE VIEW uses Item::print() methods to reconstruct the 
      statement text from the parse tree.
      The print() method for stored procedure calls needs allocate 
      space to print the function's quoted name.
      It was incorrectly calculating the length of the buffer needed 
      (was too short).
      Fixed to reflect the actual space needed.
      a6ebd634
  3. 28 May, 2007 1 commit
  4. 27 May, 2007 1 commit
  5. 26 May, 2007 3 commits
  6. 25 May, 2007 3 commits
  7. 24 May, 2007 5 commits
  8. 23 May, 2007 7 commits
  9. 22 May, 2007 10 commits
  10. 21 May, 2007 2 commits
    • igor@olga.mysql.com's avatar
      b50d17a9
    • evgen@moonbone.local's avatar
      Bug#27507: Wrong DATETIME value was allowed by ALTER TABLE in the NO_ZERO_DATE · 90aa0271
      evgen@moonbone.local authored
      mode.
      
      When a new DATE/DATETIME field without default value is being added by the
      ALTER TABLE the '0000-00-00' value is used as the default one. But it wasn't
      checked whether such value was allowed by the set sql mode. Due to this
      '0000-00-00' values was allowed for DATE/DATETIME fields even in the
      NO_ZERO_DATE mode.
      
      Now the mysql_alter_table() function checks whether the '0000-00-00' value
      is allowed for DATE/DATETIME fields by the set sql mode.
      The new error_if_not_empty flag is used in the mysql_alter_table() function
      to indicate that it should abort if the table being altered isn't empty.
      The new new_datetime_field field is used in the mysql_alter_table() function
      for error throwing purposes. 
      The new error_if_not_empty parameter is added to the copy_data_between_tables()
      function to indicate the it should return error if the source table isn't empty.
      90aa0271