- 31 May, 2006 2 commits
-
-
msvensson@shellback.(none) authored
- Part 1, fixes rpl- and federated-tests where connection is made to 127.0.0.1
-
msvensson@shellback.(none) authored
into shellback.(none):/home/msvensson/mysql/mysql-5.0
-
- 30 May, 2006 6 commits
-
-
pekka@mysql.com authored
into mysql.com:/space/pekka/ndb/version/my50
-
ramil@mysql.com authored
into mysql.com:/usr/home/ram/work/mysql-5.0
-
anozdrin@mysql.com authored
into mysql.com:/home/alik/MySQL/devel/5.0-tree
-
ramil@mysql.com authored
into mysql.com:/usr/home/ram/work/mysql-5.0
-
gluh@eagle.intranet.mysql.r18.ru authored
Bug#18282 "INFORMATION_SCHEMA.TABLES provides inconsistent info about invalid views" This bug caused crashes or resulted in wrong data being returned when one tried to obtain information from I_S tables about views using stored functions. It was caused by the fact that we were using LEX representing statement which were doing select from I_S tables as active LEX when contents of I_S table were built. So state of this LEX both affected and was affected by open_tables() calls which happened during this process. This resulted in wrong behavior and in violations of some of invariants which caused crashes. This fix tries to solve this problem by properly saving/resetting and restoring part of LEX which affects and is affected by the process of opening tables and views in get_all_tables() routine. To simplify things we separated this part of LEX in a new class and made LEX its descendant.
-
pekka@mysql.com authored
into mysql.com:/space/pekka/ndb/version/my50
-
- 29 May, 2006 20 commits
-
-
kent@mysql.com authored
-
msvensson@shellback.(none) authored
into shellback.(none):/home/msvensson/mysql/mysql-5.0
-
msvensson@neptunus.(none) authored
into neptunus.(none):/home/msvensson/mysql/mysql-5.0
-
msvensson@shellback.(none) authored
-
anozdrin@mysql.com authored
monitor interval must be > 2sec.
-
anozdrin@mysql.com authored
-
msvensson@neptunus.(none) authored
into neptunus.(none):/home/msvensson/mysql/mysql-5.0
-
msvensson@shellback.(none) authored
-
msvensson@shellback.(none) authored
-
kroki@mysql.com 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
-
- 27 May, 2006 1 commit
-
-
pekka@mysql.com authored
into mysql.com:/space/pekka/ndb/version/my50
-
- 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 4 commits
-
-
pekka@mysql.com authored
-
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
-