1. 11 Jan, 2006 1 commit
    • evgen@moonbone.local's avatar
      Fixed bug #15633: Evaluation of Item_equal for non-const table caused wrong · 605f62fc
      evgen@moonbone.local authored
      select result
      
      Item equal objects are employed only at the optimize phase. Usually they are not
      supposed to be evaluated.  Yet in some cases we call the method val_int() for
      them. Here we have to take care of restricting the predicate such an object
      represents f1=f2= ...=fn to the projection of known fields fi1=...=fik.
      
      Added a check for field's table being const in Item_equal::val_int().
      If the field's table is not const val_int() just skips that field when
      evaluating Item_equal.
      605f62fc
  2. 12 Dec, 2005 2 commits
  3. 11 Dec, 2005 2 commits
  4. 09 Dec, 2005 1 commit
  5. 08 Dec, 2005 1 commit
    • konstantin@mysql.com's avatar
      A fix and a test case for Bug#15441 "Running SP causes Server · bbf3a593
      konstantin@mysql.com authored
      to Crash": the bug was that due to non-standard name
      resolution precedence in stored procedures (See Bug#5967)
      a stored procedure variable took precedence over a table column
      when the arguments for VALUES() function were resolved.
      The implementation of VALUES() function was not designed to work
      with Item_splocal and crashed.
      VALUES() function is non-standard. It can refer to, and
      is meaningful for, table columns only. The patch disables SP 
      variables as possible arguments of VALUES() function.
      bbf3a593
  6. 07 Dec, 2005 31 commits
  7. 06 Dec, 2005 2 commits