- 03 Jun, 2006 1 commit
-
-
igor@rurik.mysql.com authored
into rurik.mysql.com:/home/igor/mysql-5.0-opt
-
- 02 Jun, 2006 6 commits
-
-
igor@rurik.mysql.com authored
into rurik.mysql.com:/home/igor/mysql-4.1-opt
-
igor@rurik.mysql.com authored
The bug report revealed two problems related to min/max optimization: 1. If the length of a constant key used in a SARGable condition for for the MIN/MAX fields is greater than the length of the field an unwanted warning on key truncation is issued; 2. If MIN/MAX optimization is applied to a partial index, like INDEX(b(4)) than can lead to returning a wrong result set.
-
gkodinov@mysql.com authored
-
gkodinov@mysql.com authored
-
gkodinov@mysql.com authored
into mysql.com:/home/kgeorge/mysql/5.0/B4981
-
gkodinov@mysql.com authored
3.23 regression test failure The member SEL_ARG::min_flag was not initialized, due to which the condition for no GEOM_FLAG in function key_or did not choose "Range checked for each record" as the correct access method.
-
- 30 May, 2006 3 commits
-
-
evgen@moonbone.local authored
After merge fix
-
evgen@moonbone.local authored
-
evgen@moonbone.local authored
into moonbone.local:/work/18360-bug-4.1-mysql-opt
-
- 29 May, 2006 16 commits
-
-
evgen@moonbone.local authored
The IN() function uses agg_cmp_type() to aggregate all types of its arguments to find out some common type for comparisons. In this particular case the char() and the int was aggregated to double because char() can contain values like '1.5'. But all strings which do not start from a digit are converted to 0. thus 'a' and 'z' become equal. This behaviour is reasonable when all function arguments are constants. But when there is a field or an expression this can lead to false comparisons. In this case it makes more sense to coerce constants to the type of the field argument. The agg_cmp_type() function now aggregates types of constant and non-constant items separately. If some non-constant items will be found then their aggregated type will be returned. Thus after the aggregation constants will be coerced to the aggregated type.
-
evgen@moonbone.local authored
-
msvensson@neptunus.(none) authored
into neptunus.(none):/home/msvensson/mysql/mysql-5.0
-
msvensson@neptunus.(none) authored
into neptunus.(none):/home/msvensson/mysql/mysql-5.0
-
msvensson@shellback.(none) authored
-
msvensson@shellback.(none) authored
-
msvensson@devsrv-b.mysql.com authored
into devsrv-b.mysql.com:/users/msvensson/mysql-5.0
-
msvensson@neptunus.(none) authored
into neptunus.(none):/home/msvensson/mysql/mysql-5.0
-
msvensson@neptunus.(none) authored
into neptunus.(none):/home/msvensson/mysql/mysql-5.0
-
msvensson@shellback.(none) authored
into shellback.(none):/home/msvensson/mysql/mysql-5.0
-
msvensson@devsrv-b.mysql.com authored
into devsrv-b.mysql.com:/users/msvensson/mysql-5.0
-
ramil@mysql.com authored
-
msvensson@neptunus.(none) authored
-
msvensson@neptunus.(none) authored
into neptunus.(none):/home/msvensson/mysql/mysql-5.0
-
ramil@mysql.com authored
-
ramil@mysql.com authored
into mysql.com:/usr/home/ram/work/mysql-5.0
-
- 28 May, 2006 1 commit
-
-
evgen@moonbone.local authored
In multi-table delete a table for delete can't be used for selecting in subselects. Appropriate error was raised but wasn't checked which leads to a crash at the execution phase. The mysql_execute_command() now checks for errors before executing select for multi-delete.
-
- 26 May, 2006 7 commits
-
-
elliot@mysql.com authored
into mysql.com:/home/emurphy/iggy/mysql-5.0
-
gkodinov@mysql.com authored
into mysql.com:/home/kgeorge/mysql/5.0/clean
-
gkodinov@mysql.com authored
into mysql.com:/home/kgeorge/mysql/5.0/B18681
-
gkodinov@mysql.com authored
into mysql.com:/home/kgeorge/mysql/5.0/B18681
-
gkodinov@mysql.com authored
into mysql.com:/home/kgeorge/mysql/5.0/B14875
-
gkodinov@mysql.com authored
When reading a view definition from a .frm file it was throwing a SQL error if the DEFINER user is not defined. Changed it to a warning to match the (documented) case when a view with undefined DEFINER user is created.
-
gkodinov@mysql.com authored
The check for view security was lacking several points : 1. Check with the right set of permissions : for each table ref that participates in a view there were the right credentials to use in it's security_ctx member, but these weren't used for checking the credentials. This makes hard enforcing the SQL SECURITY DEFINER|INVOKER property consistently. 2. Because of the above the security checking for views was just ruled out in explicit ways in several places. 3. The security was checked only for the columns of the tables that are brought into the query from a view. So if there is no column reference outside of the view definition it was not detecting the lack of access to the tables in the view in SQL SECURITY INVOKER mode. The fix below tries to fix the above 3 points.
-
- 25 May, 2006 6 commits
-
-
pekka@mysql.com authored
-
pekka@mysql.com authored
into mysql.com:/space/pekka/ndb/version/my50-bug14509
-
pekka@mysql.com authored
into mysql.com:/space/pekka/ndb/version/my50-bug14509
-
gkodinov@mysql.com authored
into mysql.com:/home/kgeorge/mysql/5.0/clean
-
gkodinov@mysql.com authored
into mysql.com:/home/kgeorge/mysql/5.0/B18742-2
-
gkodinov@mysql.com authored
into mysql.com:/home/kgeorge/mysql/5.0/B18742-2
-