- 12 Dec, 2005 3 commits
-
-
ingo@mysql.com authored
into mysql.com:/home/mydev/mysql-5.0-bug10932
-
aivanov@mysql.com authored
into mysql.com:/home/alexi/dev/mysql-5.0-14614
-
igor@rurik.mysql.com authored
Post review corrections in comments.
-
- 11 Dec, 2005 2 commits
-
-
aivanov@mysql.com authored
error message if database is changed.
-
igor@rurik.mysql.com authored
into rurik.mysql.com:/home/igor/dev/mysql-5.0-2
-
- 09 Dec, 2005 1 commit
-
-
msvensson@devsrv-b.mysql.com authored
into devsrv-b.mysql.com:/space/magnus/my50-bug9535
-
- 08 Dec, 2005 2 commits
-
-
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.
-
ingo@mysql.com authored
into mysql.com:/home/mydev/mysql-5.0-bug10932
-
- 07 Dec, 2005 32 commits
-
-
msvensson@devsrv-b.mysql.com authored
into devsrv-b.mysql.com:/space/magnus/my50-bug9535
-
dlenev@mysql.com authored
into mysql.com:/home/dlenev/src/mysql-5.0-merges
-
dlenev@mysql.com authored
into mysql.com:/home/dlenev/src/mysql-5.0-merges
-
dlenev@mysql.com authored
-
anozdrin@mysql.com authored
-
msvensson@devsrv-b.mysql.com authored
into devsrv-b.mysql.com:/space/magnus/my50-bug9535
-
msvensson@neptunus.(none) authored
into neptunus.(none):/home/msvensson/mysql/bug9535/my50-bug9535
-
ingo@mysql.com authored
into mysql.com:/home/mydev/mysql-5.0-bug10932
-
dlenev@mysql.com authored
into mysql.com:/home/dlenev/src/mysql-5.0-merges
-
konstantin@mysql.com authored
-
dlenev@mysql.com authored
into mysql.com:/home/dlenev/src/mysql-5.0-merges
-
jimw@mysql.com authored
into mysql.com:/home/jimw/my/mysql-5.0-release
-
konstantin@mysql.com authored
into mysql.com:/opt/local/work/mysql-5.0-root
-
konstantin@mysql.com authored
-
dlenev@mysql.com authored
into mysql.com:/home/dlenev/src/mysql-5.0-merges
-
msvensson@neptunus.(none) authored
- Set max_length of Item_func_uuid to max_length*system_charset_info->mbmaxlen Note! Item_func_uuid should be set to use 'ascii' charset when hex(), format(), md5() etc will use 'ascii' - Comitting again, the old patch seems to have been lost.
-
anozdrin@mysql.com authored
into mysql.com:/home/alik/Documents/AllProgs/MySQL/devel/5.0-sp-vars-merge-2
-
anozdrin@mysql.com authored
according to the standard. The idea is to use Field-classes to implement stored routines variables. Also, we should provide facade to Item-hierarchy by Item_field class (it is necessary, since SRVs take part in expressions). The patch fixes the following bugs: - BUG#8702: Stored Procedures: No Error/Warning shown for inappropriate data type matching; - BUG#8768: Functions: For any unsigned data type, -ve values can be passed and returned; - BUG#8769: Functions: For Int datatypes, out of range values can be passed and returned; - BUG#9078: STORED PROCDURE: Decimal digits are not displayed when we use DECIMAL datatype; - BUG#9572: Stored procedures: variable type declarations ignored; - BUG#12903: upper function does not work inside a function; - BUG#13705: parameters to stored procedures are not verified; - BUG#13808: ENUM type stored procedure parameter accepts non-enumerated data; - BUG#13909: Varchar Stored Procedure Parameter always BINARY string (ignores CHARACTER SET); - BUG#14161: Stored procedure cannot retrieve bigint unsigned; - BUG#14188: BINARY variables have no 0x00 padding; - BUG#15148: Stored procedure variables accept non-scalar values;
-
dlenev@mysql.com authored
current SP tables locking make impossible view security" with main tree.
-
knielsen@mysql.com authored
into mysql.com:/data0/mysqldev/my/mysql-5.0
-
knielsen@mysql.com authored
-
lenz@mysql.com authored
into mysql.com:/space/my/mysql-5.0
-
dlenev@mysql.com authored
into mysql.com:/home/dlenev/src/mysql-5.0-bg11555-2
-
lenz@mysql.com authored
into mysql.com:/space/my/mysql-5.0
-
dlenev@mysql.com authored
into mysql.com:/home/dlenev/src/mysql-5.0-bg11555-2
-
lenz@mysql.com authored
into mysql.com:/space/my/mysql-5.0-merg
-
dlenev@mysql.com authored
impossible view security". We should not expose names of tables which are explicitly or implicitly (via routine or trigger) used by view even if we find that they are missing. So during building of list of prelocked tables for statement we track which routines (and therefore tables for these routines) are used from views. We mark elements of LEX::routines set which correspond to routines used in views by setting Sroutine_hash_entry::belong_to_view member to point to TABLE_LIST object for topmost view which uses routine. We propagate this mark to all routines which are used by this routine and which we add to this set. We also mark tables used by such routine which we add to the list of tables for prelocking as belonging to this view.
-
ingo@mysql.com authored
into mysql.com:/home/mydev/mysql-5.0-bug10932
-
serg@serg.mylan authored
-
timour@mysql.com authored
into mysql.com:/home/timka/mysql/src/5.0-2486
-
lenz@mysql.com authored
into mysql.com:/space/my/mysql-4.1
-
jimw@mysql.com authored
-