- 19 Jan, 2007 2 commits
-
-
malff/marcsql@weblab.(none) authored
-
malff/marcsql@weblab.(none) authored
into weblab.(none):/home/marcsql/TREE/mysql-5.0-24562-merge
-
- 18 Jan, 2007 3 commits
-
-
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.
-
kroki/tomash@moonlight.home authored
into moonlight.home:/home/tomash/src/mysql_ab/mysql-5.0-bug24404
-
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.
-
- 17 Jan, 2007 4 commits
-
-
kostja@bodhi.local authored
-
kostja@bodhi.local authored
into bodhi.local:/opt/local/work/mysql-5.0-runtime-debug-max
-
kostja@bodhi.local authored
by the patch for Bug#4968
-
kostja@bodhi.local authored
-
- 16 Jan, 2007 3 commits
-
-
kostja@bodhi.local authored
into bodhi.local:/opt/local/work/mysql-5.0-runtime
-
kostja@bodhi.local authored
-
dlenev@mockturtle.local authored
into mockturtle.local:/home/dlenev/src/mysql-5.0-bg20390-2
-
- 15 Jan, 2007 11 commits
-
-
malff/marcsql@weblab.(none) authored
into weblab.(none):/home/marcsql/TREE/mysql-5.0-6298
-
kostja@bodhi.local authored
into bodhi.local:/opt/local/work/mysql-5.0-runtime
-
kostja@bodhi.local authored
into bodhi.local:/opt/local/work/mysql-5.0-runtime
-
kostja@bodhi.local authored
-
-
joerg@trift2. authored
into trift2.:/MySQL/M50/push-5.0
-
dlenev@mockturtle.local authored
into mockturtle.local:/home/dlenev/src/mysql-5.0-bg20390-2
-
kostja@bodhi.local authored
into bodhi.local:/opt/local/work/mysql-5.0-4968-to-push
-
kostja@bodhi.local authored
-
kostja@bodhi.local authored
into bodhi.local:/opt/local/work/mysql-4.1-4968-to-push
-
dlenev@mockturtle.local authored
of untouched rows in full table scans". SELECT ... FOR UPDATE/LOCK IN SHARE MODE statements as well as UPDATE/DELETE statements which were executed using full table scan were not releasing locks on rows which didn't satisfy WHERE condition. This bug surfaced in 5.0 and affected NDB tables. (InnoDB tables intentionally don't support such unlocking in default mode). This problem occured because code implementing join didn't call handler::unlock_row() for rows which didn't satisfy part of condition attached to this particular table/level of nested loop. So we solve the problem adding this call. Note that we already had this call in place in 4.1 but it was lost (actually not quite correctly placed) when we have introduced nested joins. Also note that additional QA should be requested once this patch is pushed as interaction between handler::unlock_row() and many recent MySQL features such as subqueries, unions, views is not tested enough.
-
- 12 Jan, 2007 9 commits
-
-
kostja@bodhi.local authored
into bodhi.local:/opt/local/work/mysql-5.0-runtime
-
kostja@bodhi.local authored
into bodhi.local:/opt/local/work/mysql-5.0-runtime
-
joerg@trift2. authored
into trift2.:/MySQL/M50/push-5.0
-
kostja@bodhi.local authored
into bodhi.local:/opt/local/work/mysql-4.1-runtime
-
joerg@trift2. authored
into trift2.:/MySQL/M41/mysql-4.1
-
gluh@mysql.com/eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.0
-
gluh@mysql.com/eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.0
-
joerg@trift2. authored
into trift2.:/MySQL/M41/push-4.1
-
mmj@tiger.mmj.dk authored
Patch from Paul DuBois for better help messages
-
- 11 Jan, 2007 8 commits
-
-
kostja@bodhi.local authored
into bodhi.local:/opt/local/work/mysql-5.0-runtime
-
kostja@bodhi.local authored
into bodhi.local:/opt/local/work/mysql-5.0-runtime
-
kostja@bodhi.local authored
into bodhi.local:/opt/local/work/mysql-4.1-runtime
-
gkodinov/kgeorge@rakia.gmz authored
into rakia.gmz:/home/kgeorge/mysql/autopush/B25106-5.0-opt
-
gkodinov/kgeorge@macbook.gmz authored
aliases ignored When a column reference to a column in JOIN USING is resolved and a new Item is created for this column the user defined name was lost. This fix preserves the alias by setting the name of the new Item to the original alias.
-
kent@mysql.com/kent-amd64.(none) authored
into mysql.com:/home/kent/bk/tmp2/mysql-5.0-build
-
kent@mysql.com/kent-amd64.(none) authored
Reverted change for bug#13859, applied smaller patch from Marko
-
joerg@trift2. authored
into trift2.:/MySQL/M50/push-5.0
-