1. 19 Jan, 2007 1 commit
  2. 18 Jan, 2007 3 commits
    • malff/marcsql@weblab.(none)'s avatar
      Bug#24562 (ALTER TABLE ... ORDER BY ... with complex expression asserts) · 436e1f59
      malff/marcsql@weblab.(none) authored
      WL#3681 (ALTER TABLE ORDER BY)
      
      Before this fix, the ALTER TABLE statement implemented an ORDER BY option
      with the following characteristics :
      
      1) The order by clause accepts a list of criteria, with optional ASC or
      DESC keywords
      
      2) Each criteria can be a general expression, involving operators,
      native functions, stored functions, user defined functions, subselects ...
      
      With this fix :
      
      1) has been left unchanged, since it's a de-facto existing feature,
      that was already present in the code base and partially covered in the test
      suite. Code coverage for ASC and DESC was missing and has been improved.
      
      2) has been changed to limit the kind of criteria that are permissible:
      now only a column name is valid.
      436e1f59
    • kroki/tomash@moonlight.home's avatar
      Merge moonlight.home:/home/tomash/src/mysql_ab/mysql-5.0 · ec21b828
      kroki/tomash@moonlight.home authored
      into  moonlight.home:/home/tomash/src/mysql_ab/mysql-5.0-bug24404
      ec21b828
    • kroki/tomash@moonlight.home's avatar
      Bug#24404: strange bug with view+permission+prepared statement. · 6e771358
      kroki/tomash@moonlight.home authored
      The problem was that if a prepared statement accessed a view, the
      access to the tables listed in the query after that view was done in
      the security context of the view.
      
      The bug was in the assigning of the security context to the tables
      belonging to a view: we traversed the list of all query tables
      instead.  It didn't show up in the normal (non-prepared) statements
      because of the different order of the steps of checking privileges
      and descending into a view for normal and prepared statements.
      
      The solution is to traverse the list and stop once the last table
      belonging to the view was processed.
      6e771358
  3. 17 Jan, 2007 4 commits
  4. 16 Jan, 2007 3 commits
  5. 15 Jan, 2007 11 commits
  6. 12 Jan, 2007 9 commits
  7. 11 Jan, 2007 9 commits