There's currently no way of knowing the determinicity of an UDF.
And the optimizer and the sequence() UDFs were making wrong
assumptions about what the is_const member means.
Plus there was no implementation of update_system_tables()
causing the optimizer to overwrite the information returned by
the <udf>_init function.
Fixed by equating the assumptions about the semantics of
is_const and providing a implementation of update_used_tables().
Added a TODO item for the UDF API change needed to make a better
implementation.
during udf initialization. The bug is spotted while working on Bug 12713.
If a user-defined function was used in a SELECT statement, and an
error would occur during UDF initialization, this error would not terminate
execution of the SELECT, but rather would be converted to a warning.
The fix is to use a stack buffer to store the message from udf_init instead
of private my_error() buffer.
There are two problems with ROUND(X, D) on an exact numeric
(DECIMAL, NUMERIC type) field of a table:
1) The implementation of the ROUND function would change the number of decimal
places regardless of the value decided upon in fix_length_and_dec. When the
number of decimal places is not constant, this would cause an inconsistent
state where the number of digits was less than the number of decimal places,
which crashes filesort.
Fixed by not allowing the ROUND operation to add any more decimal places than
was decided in fix_length_and_dec.
2) fix_length_and_dec would allow the number of decimals to be greater than
the maximium configured value for constant values of D. This led to the same
crash as in (1).
Fixed by not allowing the above in fix_length_and_dec.
ucs2 doesn't provide required by fulltext ctype array. Crash
happens because fulltext attempts to use unitialized ctype
array.
Fixed by converting ucs2 fields to compatible utf8 analogue.
Previously, UDF *_init functions were passed constant strings with erroneous lengths. The length came from the containing variable's size, not the length of the value itself.
Now the *_init functions get the constant as a null terminated string with the correct length supplied too.
This actually, fix for the patch for bug-27354. The problem with
the patch was that Item_func_sp::used_tables() was updated, but
Item_func_sp::const_item() was not. So, for Item_func_sp, we had
the following inconsistency:
- used_tables() returned RAND_TABLE, which means that the item
can produce "random" results;
- but const_item() returned TRUE, which means that the item is
a constant one.
The fix is to change Item_func_sp::const_item() behaviour: it must
return TRUE (an item is a constant one) only if a stored function
is deterministic and each of its arguments (if any) is a constant
item.
When calculating the result length of an integer DIV function
the number of decimals was used without checking the result type
first. Thus an uninitialized number of decimals was used for some
types. This caused an excessive amount of memory to be allocated
for the field's buffer and crashed the server.
Fixed by using the number of decimals only for data types that
can have decimals and thus have valid decimals number.
type of the result.
There are several functions that accept parameters of different types.
The result field type of such functions was determined based on
the aggregated result type of its arguments. As the DATE and the DATETIME
types are represented by the STRING type, the result field type
of the affected functions was always STRING for DATE/DATETIME arguments.
The affected functions are COALESCE, IF, IFNULL, CASE, LEAST/GREATEST, CASE.
Now the affected functions aggregate the field types of their arguments rather
than their result types and return the result of aggregation as their result
field type.
The cached_field_type member variable is added to the number of classes to
hold the aggregated result field type.
The str_to_date() function's result field type now defaults to the
MYSQL_TYPE_DATETIME.
The agg_field_type() function is added. It aggregates field types with help
of the Field::field_type_merge() function.
The create_table_from_items() function now uses the
item->tmp_table_field_from_field_type() function to get the proper field
when the item is a function with a STRING result type.
Faster thr_alarm()
Added 'Opened_files' status variable to track calls to my_open()
Don't give warnings when running mysql_install_db
Added option --source-install to mysql_install_db
I had to do the following renames() as used polymorphism didn't work with Forte compiler on 64 bit systems
index_read() -> index_read_map()
index_read_idx() -> index_read_idx_map()
index_read_last() -> index_read_last_map()
Previously, UDF *_init functions were passed constant strings with erroneous lengths.
The length came from the containing variable's size, not the length of the value itself.
Now the *_init functions get the constant as a null terminated string with the correct
length supplied.
(Regression, caused by a patch for the bug 22646).
Problem: when result type of date_format() was changed from
binary string to character string, mixing date_format()
with a ascii column in CONCAT() stopped to work.
Fix:
- adding "repertoire" flag into DTCollation class,
to mark items which can return only pure ASCII strings.
- allow character set conversion from pure ASCII to other character sets.
Problem: thd->thread_specific_used flag is not set executing a statement
containig connection_id() function using PS protocol, that leads to
improper binlog event creation.
Fix: set the flag in the Item_func_connection_id::fix_fields().
restores from mysqlbinlog out
Problem: using "mysqlbinlog | mysql" for recoveries the connection_id()
result may differ from what was used when issuing the statement.
Fix: if there is a connection_id() in a statement, write to binlog
SET pseudo_thread_id= XXX; before it and use the value later on.
Optimization of queries with DETERMINISTIC functions in the
WHERE clause was not effective: sequential scan was always
used.
Now a SF with the DETERMINISTIC flags is treated as constant
when it's arguments are constants (or a SF doesn't has arguments).
DECIMAL column was used instead of BIGINT for the minimal possible
BIGINT (-9223372036854775808).
The Item_func_neg::fix_length_and_dec has been adjusted to
to inherit the type of the argument in the case when it's an
Item_int object whose value is equal to LONGLONG_MIN.
of its arguments was evaluated to NULL, while the predicate
LOCATE(str,NULL) IS NULL erroneously was evaluated to FALSE.
This happened because the Item_func_locate::fix_length_and_dec
method by mistake set the value of the maybe_null flag for
the function item to 0. In consequence of this the function
was considered as the one that could not ever return NULL.
was erroneously converted to double, while the result of
ROUND(<decimal expr>, <int literal>) was preserved as decimal.
As a result of such a conversion the value of ROUND(D,A) could
differ from the value of ROUND(D,val(A)) if D was a decimal expression.
Now the result of the ROUND function is never converted to
double if the first argument is decimal.
- fixed wrong test case for bug 20903
- closed the dangling connections in trigger.test
- GET_LOCK() and RELEASE_LOCK() now produce more detailed log
- fixed an omission in GET_LOCK() : assign the thread_id when
acquiring the lock.
