An error occurred fetching the project authors.
- 27 Mar, 2007 1 commit
-
-
iggy@recycle.(none) authored
- mysqldump executes a SHOW CREATE VIEW statement to generate the text that it outputs. When the function name is retrieved it's database name is unconditionally prepended. This change causes the function's database name to be prepended only when it was used to define the function.
-
- 09 Mar, 2007 1 commit
-
-
anozdrin/alik@booka.opbmk authored
-
- 07 Mar, 2007 1 commit
-
-
evgen@moonbone.local authored
result. For built-in functions like sqrt() function names are hard-coded and can be compared by pointer. But this isn't the case for a used-defined stored functions - names there are dynamical and should be compared as strings. Now the Item_func::eq() function employs my_strcasecmp() function to compare used-defined stored functions names.
-
- 02 Mar, 2007 1 commit
-
-
malff/marcsql@weblab.(none) authored
results) Before this fix, the function BENCHMARK() would fail to evaluate expressions like "(select avg(a) from t1)" in debug builds (with an assert), or would report a time of zero in non debug builds. The root cause is that evaluation of DECIMAL_RESULT expressions was not supported in Item_func_benchmark::val_int(). This has been fixed by this change.
-
- 23 Feb, 2007 1 commit
-
-
cbell/Chuck@mysql_cab_desk. authored
Triggers in SBR mode." BUG#14914 "SP: Uses of session variables in routines are not always replicated" BUG#25167 "Dupl. usage of user-variables in trigger/function is not replicated correctly" User-defined variables used inside of stored functions/triggers in statements which did not update tables directly were not replicated. We also had problems with replication of user-defined variables which were used in triggers (or stored functions called from table-updating statements) more than once. This patch addresses the first issue by enabling logging of all references to user-defined variables in triggers/stored functions and not only references from table-updating statements. The second issue stemmed from the fact that for user-defined variables used from triggers or stored functions called from table-updating statements we were writing binlog events for each reference instead of only one event for the first reference. This problem is already solved for stored functions called from non-updating statements with help of "event unioning" mechanism. So the patch simply extends this mechanism to the case affected. It also fixes small problem in this mechanism which caused wrong logging of references to user-variables in cases when non-updating statement called several stored functions which used the same variable and some of these function calls were omitted from binlog as they were not updating any tables.
-
- 26 Jan, 2007 1 commit
-
-
igor@olga.mysql.com authored
The bug report has demonstrated the following two problems. 1. If an ORDER/GROUP BY list includes a constant expression being optimized away and, at the same time, containing single-row subselects that return more that one row, no error is reported. Strictly speaking the standard allows to ignore error in this case. Yet, now a corresponding fatal error is reported in this case. 2. If a query requires sorting by expressions containing single-row subselects that, however, return more than one row, then the execution of the query may cause a server crash. To fix this some code has been added that blocks execution of a subselect item in case of a fatal error in the method Item_subselect::exec.
-
- 22 Jan, 2007 1 commit
-
-
igor@olga.mysql.com authored
The bug is actually a duplicate of the bug 14708. Down-ported the fix for 14708 from 5.0. Merged the test case for bug 14708 from 5.0.
-
- 18 Jan, 2007 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
crashes server Check for null value is reliable only after calling some of the val_xxx() methods. If the val_xxx() method is not called the null_value flag will be set only for certain types of NULL values (like SQL constant NULLs for example). This caused a crash while trying to dereference a NULL pointer that is returned by val_str() for NULL values. Fixed by swapping the order of val_xxx() and null_value check.
-
- 09 Jan, 2007 2 commits
-
-
evgen@moonbone.local authored
used. The Item::save_in_field() function is called from fill_record() to fill the new row with data while execution of the CREATE TABLE ... SELECT statement. Item::save_in_field() calls val_xxx() methods in order to get values. val_xxx() methods do not take into account the result field. Due to this Item_func_set_user_var::val_xxx() methods returns values from the original table, not from the temporary one. The save_in_field() member function is added to the Item_func_set_user_var class. It detects whether the result field should be used and properly updates the value of the user variable.
-
kroki/tomash@moonlight.home authored
server The problem was that when memory was exhausted HEAP engine could crash (GROUP BY uses HEAP TABLE). Alternatively, if SET was used, it could report an error "You may only use constant expressions with SET" instead of "Out of memory (Needed NNNNNN bytes)". The solution is: - pass MY_WME to (some) calls to my_malloc() to get correct message. - fix heap_write() so that the first key is skipped during cleanup on ENOMEM because it wasn't inserted and doesn't have to be deleted. No test case is provided because we can't test out-of-memory behaviour in our current test framework.
-
- 23 Dec, 2006 1 commit
-
-
kent@mysql.com/kent-amd64.(none) authored
Changed header to GPL version 2 only
-
- 14 Dec, 2006 1 commit
-
-
monty@mysql.com/narttu.mysql.fi authored
- Removed not used variables and functions - Added #ifdef around code that is not used - Renamed variables and functions to avoid conflicts - Removed some not used arguments Fixed some class/struct warnings in ndb Added define IS_LONGDATA() to simplify code in libmysql.c I did run gcov on the changes and added 'purecov' comments on almost all lines that was not just variable name changes
-
- 04 Dec, 2006 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
fixed a valgrind warning type_varchar.test: fixed a valgrind warning
-
- 30 Nov, 2006 1 commit
-
-
monty@mysql.com/narttu.mysql.fi authored
Fixed compiler warnings (detected by VC++): - Removed not used variables - Added casts - Fixed wrong assignments to bool - Fixed wrong calls with bool arguments - Added missing argument to store(longlong), which caused wrong store method to be called.
-
- 15 Nov, 2006 1 commit
-
-
cmiller@zippy.cornsilk.net authored
Problem: When we have a really large number (between 2^63 and 2^64) as the left side of the mod operator, it gets improperly corerced into a signed value. Solution: Added check to see if the "negative" number is really positive, and if so, cast it.
-
- 13 Nov, 2006 3 commits
-
-
cmiller@zippy.cornsilk.net authored
The code that set up data to be passed to user-defined functions was very old and analyzed the "Type" of the data that was passed into the UDF, when it really should analyze the "return_type", which is hard-coded for simple Items and works correctly for complex ones like functions. --- Added test at Sergei's behest.
-
dlenev@mockturtle.local authored
stored function invoked from different connections". Invocation of trigger which was using stored function from different connections caused server crashes (for non-debug server this happened in highly concurrent environment, but debug server failed on assertion in relatively simple scenario). Item_func_sp was not safe to use in triggers (in other words for re-execution from different threads) as artificial TABLE object pointed by Item_func_sp::dummy_table referenced incorrect THD object. To fix the problem we force re-initialization of this object for each re-execution of statement.
-
holyfoot/hf@mysql.com/deer.(none) authored
-
- 08 Nov, 2006 1 commit
-
-
cmiller@zippy.cornsilk.net authored
on large length Problem: Most (all) of the numeric inputs were being coerced into int (32 bit) sized variables. Works OK for sane inputs; any input larger than 2^32 (or 2^31 for signed vars) exihibited predictable wrapping behavior (up to about 10^18) and then started having really strange behaviour past that point (since the conversion to 64 bit int from the DECIMAL type can do weird things on out of range numbers). Solution: 1) Add many tests. 2) Convert input from (u)long type to (u)longlong. 3) Do (sometimes multiple) sanity checks on input, keeping in mind that sometimes a negative longlong is not a negative longlong (if the unsigned_flag is set). 4) Emulate existing behavior w/rt negative and "small" out-of-bounds values.
-
- 06 Nov, 2006 1 commit
-
-
cmiller@zippy.cornsilk.net authored
The Item_func_mod objects never had maybe_null set, so users had no reason to expect that they can be NULL, and may therefore deduce wrong results. Now, set maybe_null.
-
- 30 Oct, 2006 1 commit
-
-
holyfoot/hf@mysql.com/deer.(none) authored
decimal->ulong conversion fixed to assign max possible ULONG if decimal is bigger Item_func_unsigned now handles DECIMAL parameter separately as we can't rely on decimal::val_int result here.
-
- 24 Oct, 2006 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
select OK. The SQL parser was using Item::name to transfer user defined function attributes to the user defined function (udf). It was not distinguishing between user defined function call arguments and stored procedure call arguments. Setting Item::name was causing Item_ref::print() method to print the argument as quoted identifiers and caused views that reference aggregate functions as udf call arguments (and rely on Item::print() for the text of the view to store) to throw an undefined identifier error. Overloaded Item_ref::print to print aggregate functions as such when printing the references to aggregate functions taken out of context by split_sum_func2() Fixed the parser to properly detect using AS clause in stored procedure arguments as an error. Fixed printing the arguments of udf call to print properly the udf attribute.
-
- 06 Oct, 2006 1 commit
-
-
kroki/tomash@moonlight.intranet authored
Note: bug#21726 does not directly apply to 4.1, as it doesn't have stored procedures. However, 4.1 had some bugs that were fixed in 5.0 by the patch for bug#21726, and this patch is a backport of those fixes. Namely, in 4.1 it fixes: - LAST_INSERT_ID(expr) didn't return value of expr (4.1 specific). - LAST_INSERT_ID() could return the value generated by current statement if the call happens after the generation, like in CREATE TABLE t1 (i INT AUTO_INCREMENT PRIMARY KEY, j INT); INSERT INTO t1 VALUES (NULL, 0), (NULL, LAST_INSERT_ID()); - Redundant binary log LAST_INSERT_ID_EVENTs could be generated.
-
- 03 Oct, 2006 1 commit
-
-
kroki/tomash@moonlight.intranet authored
invocations of LAST_INSERT_ID. Reding of LAST_INSERT_ID inside stored function wasn't noted by caller, and no LAST_INSERT_ID_EVENT was issued for binary log. The solution is to add THD::last_insert_id_used_bin_log, which is much like THD::last_insert_id_used, but is reset only for upper-level statements. This new variable is used to issue LAST_INSERT_ID_EVENT.
-
- 02 Oct, 2006 1 commit
-
-
kroki/tomash@moonlight.intranet authored
Non-upper-level INSERTs (the ones in the body of stored procedure, stored function, or trigger) into a table that have AUTO_INCREMENT column didn't affected the result of LAST_INSERT_ID() on this level. The problem was introduced with the fix of bug 6880, which in turn was introduced with the fix of bug 3117, where current insert_id value was remembered on the first call to LAST_INSERT_ID() (bug 3117) and was returned from that function until it was reset before the next _upper-level_ statement (bug 6880). The fix for bug#21726 brings back the behaviour of version 4.0, and implements the following: remember insert_id value at the beginning of the statement or expression (which at that point equals to the first insert_id value generated by the previous statement), and return that remembered value from LAST_INSERT_ID() or @@LAST_INSERT_ID. Thus, the value returned by LAST_INSERT_ID() is not affected by values generated by current statement, nor by LAST_INSERT_ID(expr) calls in this statement. Version 5.1 does not have this bug (it was fixed by WL 3146).
-
- 13 Sep, 2006 2 commits
-
-
kaa@polly.local authored
-
kaa@polly.local authored
Cset exclude: kaa@polly.local|ChangeSet|20060908100829|09983
-
- 12 Sep, 2006 2 commits
-
-
kaa@polly.local authored
-
kaa@polly.local authored
-
- 09 Sep, 2006 1 commit
-
-
igor@rurik.mysql.com authored
-
- 08 Sep, 2006 1 commit
-
-
kaa@polly.local authored
- Honor unsigned_flag in the corresponding functions - Use compare_int_signed_unsigned()/compare_int_unsigned_signed() instead of explicit comparison in GREATEST() and LEAST()
-
- 07 Sep, 2006 1 commit
-
-
igor@rurik.mysql.com authored
equal constant under any circumstances. In fact this substitution can be allowed if the field is not of a type string or if the field reference serves as an argument of a comparison predicate.
-
- 24 Aug, 2006 1 commit
-
-
kroki/tomash@moonlight.intranet authored
Changes in an item tree done by optimizer weren't properly registered and went unnoticed, which resulted in preliminary freeing of used memory.
-
- 22 Aug, 2006 2 commits
-
-
evgen@moonbone.local authored
Additional fix for bug #21475 item_func.h, item_func.cc: Additional fix for bug#16861
-
evgen@sunlight.local authored
used. Sorting by RAND() uses a temporary table in order to get a correct results. User defined variable was set during filling the temporary table and later on it is substituted for its value from the temporary table. Due to this it contains the last value stored in the temporary table. Now if the result_field is set for the Item_func_set_user_var object it updates variable from the result_field value when being sent to a client. The Item_func_set_user_var::check() now accepts a use_result_field parameter. Depending on its value the result_field or the args[0] is used to get current value.
-
- 26 Jul, 2006 1 commit
-
-
evgen@moonbone.local authored
Post review changes for bug#19862.
-
- 25 Jul, 2006 1 commit
-
-
evgen@moonbone.local authored
When there is no index defined filesort is used to sort the result of a query. If there is a function in the select list and the result set should be ordered by it's value then this function will be evaluated twice. First time to get the value of the sort key and second time to send its value to a user. This happens because filesort when sorts a table remembers only values of its fields but not values of functions. All functions are affected. But taking into account that SP and UDF functions can be both expensive and non-deterministic a temporary table should be used to store their results and then sort it to avoid twice SP evaluation and to get a correct result. If an expression referenced in an ORDER clause contains a SP or UDF function, force the use of a temporary table. A new Item_processor function called func_type_checker_processor is added to check whether the expression contains a function of a particular type.
-
- 13 Jul, 2006 1 commit
-
-
kroki/tomash@moonlight.intranet authored
context. Routine arguments were evaluated in the security context of the routine itself, not in the caller's context. The bug is fixed the following way: - Item_func_sp::find_and_check_access() has been split into two functions: Item_func_sp::find_and_check_access() itself only finds the function and check that the caller have EXECUTE privilege on it. New function set_routine_security_ctx() changes security context for SUID routines and checks that definer have EXECUTE privilege too. - new function sp_head::execute_trigger() is called from Table_triggers_list::process_triggers() instead of sp_head::execute_function(), and is effectively just as the sp_head::execute_function() is, with all non-trigger related code removed, and added trigger-specific security context switch. - call to Item_func_sp::find_and_check_access() stays outside of sp_head::execute_function(), and there is a code in sql_parse.cc before the call to sp_head::execute_procedure() that checks that the caller have EXECUTE privilege, but both sp_head::execute_function() and sp_head::execute_procedure() call set_routine_security_ctx() after evaluating their parameters, and restore the context after the body is executed.
-
- 09 Jul, 2006 1 commit
-
-
kostja@bodhi.local authored
between pointer to function and pointer to object.
-
- 30 Jun, 2006 1 commit
-
-
knielsen@mysql.com authored
In some functions dealing with strings and character sets, the wrong pointers were saved for restoration in THD::rollback_item_tree_changes(). This could potentially cause random corruption or crashes. Fixed by passing the original Item ** locations, not local stack copies. Also remove unnecessary use of default arguments.
-