An error occurred fetching the project authors.
- 23 Jan, 2007 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
RAND() must accept scalar expressions regardless of their kind. That includes both constant expressions and expressions that depend on column values. When the expression is constant the random seed can be initialized at compile time. However when the expression is not constant the random seed must be initialized at each invocation (while it still can be allocated at compile time). Implemented the above rules by extending Item_func_rand::val_real() to initialize the random seed at the correct place.
-
- 09 Jan, 2007 1 commit
-
-
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.
-
- 23 Dec, 2006 1 commit
-
-
kent@mysql.com/kent-amd64.(none) authored
Changed header to GPL version 2 only
-
- 04 Dec, 2006 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
fixed a valgrind warning type_varchar.test: fixed a valgrind warning
-
- 02 Dec, 2006 1 commit
-
-
brian@zim.(none) authored
This finishes the work (someone) started to remove FIELD_ types and use the Enum MYSQL types. The second part to this is to actually deprecate the FIELD defines in mysql_com.h
-
- 30 Nov, 2006 2 commits
-
-
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.
-
monty@mysql.com/narttu.mysql.fi authored
- Removed not used variables - Changed some ulong parameters/variables to ulonglong (possible serious bug) - Added casts to get rid of safe assignment from longlong to long (and similar) - Added casts to function parameters - Fixed signed/unsigned compares - Added some constructores to structures - Removed some not portable constructs Better fix for bug Bug #21428 "skipped 9 bytes from file: socket (3)" on "mysqladmin shutdown" (Added new parameter to net_clear() to define when we want the communication buffer to be emptied)
-
- 26 Nov, 2006 1 commit
-
-
monty@mysql.com/nosik.monty.fi authored
Added missing DBUG_RETURN statements (in mysqldump.c) Added missing enums Fixed a lot of wrong DBUG_PRINT() statements, some of which could cause crashes Removed usage of %lld and %p in printf strings as these are not portable or produces different results on different systems.
-
- 17 Nov, 2006 1 commit
-
-
Fix tests for new behaviour: an error is thrown if a NON DETERMINISTIC stored function (SF) is called during statement-based replication (SBR).
-
- 16 Nov, 2006 1 commit
-
-
malff/marcsql@weblab.(none) authored
Before this change, the functions BENCHMARK, ENCODE, DECODE and FORMAT could only accept a constant for some parameters. After this change, this restriction has been removed. An implication is that these functions can also be used in prepared statements. The change consist of changing the following classes: - Item_func_benchmark - Item_func_encode - Item_func_decode - Item_func_format to: - only accept Item* in the constructor, - and evaluate arguments during calls to val_xxx() which fits the general design of all the other functions. The 'TODO' items identified in item_create.cc during the work done for Bug 21114 are addressed by this fix, as a natural consequence of aligning the design. In the 'func_str' test, a single very long test line involving an explain extended select with many functions has been rewritten into multiple separate tests, to improve maintainability. The result of explain extended select decode(encode(...)) has changed, since the encode and decode functions now print all their parameters.
-
- 15 Nov, 2006 2 commits
-
-
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.
-
calling (rather than defining) non-deterministic SP in SBR (as opposed to RBR or mixed) will throw an error now. require mixed mode for tests now. SBR will now fail when calling non-deter SPs and SFs (as it should), and RBR already failed by virtue of giving different results for "show binlog" than the results-file has. also test for 16456 now. lastly make amends because one of the tests fails with a new error # now as code was added to sql_trigger.cc while test was disabled.
-
- 13 Nov, 2006 4 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
trigger which uses stored function invoked from different connections" into 5.1.
-
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 3 commits
-
-
kaa@polly.local authored
-
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.
-
- 08 Aug, 2006 1 commit
-
-
gluh@mysql.com/gluh.(none) authored
issue an 'overflow warning' if result value is bigger than max possible 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 2 commits
-
-
guilhem@gbichot3.local authored
this is a cleanup patch for our current auto_increment handling: new names for auto_increment variables in THD, new methods to manipulate them (see sql_class.h), some move into handler::, causing less backup/restore work when executing substatements. This makes the logic hopefully clearer, less work is is needed in mysql_insert(). By cleaning up, using different variables for different purposes (instead of one for 3 things...), we fix those bugs, which someone may want to fix in 5.0 too: BUG#20339 "stored procedure using LAST_INSERT_ID() does not replicate statement-based" BUG#20341 "stored function inserting into one auto_increment puts bad data in slave" BUG#19243 "wrong LAST_INSERT_ID() after ON DUPLICATE KEY UPDATE" (now if a row is updated, LAST_INSERT_ID() will return its id) and re-fixes: BUG#6880 "LAST_INSERT_ID() value changes during multi-row INSERT" (already fixed differently by Ramil in 4.1) Test of documented behaviour of mysql_insert_id() (there was no test). The behaviour changes introduced are: - LAST_INSERT_ID() now returns "the first autogenerated auto_increment value successfully inserted", instead of "the first autogenerated auto_increment value if any row was successfully inserted", see auto_increment.test. Same for mysql_insert_id(), see mysql_client_test.c. - LAST_INSERT_ID() returns the id of the updated row if ON DUPLICATE KEY UPDATE, see auto_increment.test. Same for mysql_insert_id(), see mysql_client_test.c. - LAST_INSERT_ID() does not change if no autogenerated value was successfully inserted (it used to then be 0), see auto_increment.test. - if in INSERT SELECT no autogenerated value was successfully inserted, mysql_insert_id() now returns the id of the last inserted row (it already did this for INSERT VALUES), see mysql_client_test.c. - if INSERT SELECT uses LAST_INSERT_ID(X), mysql_insert_id() now returns X (it already did this for INSERT VALUES), see mysql_client_test.c. - NDB now behaves like other engines wrt SET INSERT_ID: with INSERT IGNORE, the id passed in SET INSERT_ID is re-used until a row succeeds; SET INSERT_ID influences not only the first row now. Additionally, when unlocking a table we check that the thread is not keeping a next_insert_id (as the table is unlocked that id is potentially out-of-date); forgetting about this next_insert_id is done in a new handler::ha_release_auto_increment(). Finally we prepare for engines capable of reserving finite-length intervals of auto_increment values: we store such intervals in THD. The next step (to be done by the replication team in 5.1) is to read those intervals from THD and actually store them in the statement-based binary log. NDB will be a good engine to test that.
-
kostja@bodhi.local authored
between pointer to function and pointer to object.
-