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.
The fix is a copy of Martin Friebe's suggestion.
added testing for no_appended which will be false if anything,
including the empty string is in result
doesn't recognize it
This is a 5.0 version of the patch, it will be null-merged to 5.1
Problem:
'log' and 'log_slow_queries' were "fixed" variables, i.e. they showed up
in SHOW VARIABLES, but could not be used in expressions like
"select @@log". Also, using them in the SET statement produced an
incorrect "unknown system variable" error.
Solution:
Make 'log' and 'log_slow_queries' read-only dynamic variables to make
them available for use in expressions, and produce a correct error
about the variable being read-only when used in the SET statement.
all space column names.
The parser has been modified to check VIEW column names
with the check_column_name function and to report an error
on empty and all space column names (same as for TABLE
column names).
file .\opt_sum.cc, line
The optimizer pre-calculates the MIN/MAX values for queries like
SELECT MIN(kp_k) WHERE kp_1 = const AND ... AND kp_k-1 = const
when there is a key over kp_1...kp_k
In doing so it was not checking correctly nullability and
there was a superfluous assert().
Fixed by making sure that the field can be null before checking and
taking out the wrong assert().
.
Introduced a correct check for nullability
The MIN(field) can return NULL when all the row values in the group
are NULL-able or if there were no rows.
Fixed the assertion to reflect the case when there are no rows.
in the SELECT INTO OUTFILE clause starts with a special
character (one of n, t, r, b, 0, Z or N) and ENCLOSED BY
is empty, every occurrence of this character within a
field value is duplicated.
Duplication has been avoided.
New warning message has been added: "First character of
the FIELDS TERMINATED string is ambiguous; please use
non-optional and non-empty FIELDS ENCLOSED BY".
When doing indexed search the server constructs a key image for
faster comparison to the stored keys. While doing that it must not
perform (and stop if they fail) the additional date checks that can
be turned on by the SQL mode because there already may be values in
the table that don't comply with the error checks.
Fixed by ignoring these SQL mode bits while making the key image.
an error, asserts server
In case of a fatal error during filesort in find_all_keys() the error
was returned without the necessary handler uninitialization.
Fixed by changing the code so that handler uninitialization is performed
before returning the error.
Since, as of MySQL 5.0.15, CHAR() arguments larger than 255 are converted into multiple result bytes, a single CHAR() argument can now take up to 4 bytes. This patch fixes Item_func_char::fix_length_and_dec() to take this into account.
This patch also fixes a regression introduced by the patch for bug21513. As now we do not always have the 'name' member of Item set for Item_hex_string and Item_bin_string, an own print() method has been added to Item_hex_string so that it could correctly be printed by Item_func::print_args().
No warning was generated when a TIMESTAMP with a non-zero time part
was converted to a DATE value. This caused index lookup to assume
that this is a valid conversion and was returning rows that match
a comparison between a TIMESTAMP value and a DATE keypart.
Fixed by generating a warning on such a truncation.
Buffer used when setting variables was not dimensioned to accomodate
trailing '\0'. An overflow by one character was therefore possible.
CS corrects limits to prevent such overflows.
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.
The root cause of the issue was that the CREATE FUNCTION grammar,
for User Defined Functions, was using the sp_name rule.
The sp_name rule is intended for fully qualified stored procedure names,
like either ident.ident, or just ident but with a default database
implicitly selected.
A UDF does not have a fully qualified name, only a name (ident), and should
not use the sp_name grammar fragment during parsing.
The fix is to re-organize the CREATE FUNCTION grammar, to better separate:
- creating UDF (no definer, can have AGGREGATE, simple ident)
- creating Stored Functions (definer, no AGGREGATE, fully qualified name)
With the test case provided, another issue was exposed which is also fixed:
the DROP FUNCTION statement was using sp_name and also failing when no database
is implicitly selected, when droping UDF functions.
The fix is also to change the grammar so that DROP FUNCTION works with
both the ident.ident syntax (to drop a stored function), or just the ident
syntax (to drop either a UDF or a Stored Function, in the current database)
makedate() will fold years below 100 into the 1970-2069 range. CS removes code
that also wrongly folded years between 100 and 200 into that range, which should
be left unchanged. Backport from 5.1.
Problem: GROUP_CONCAT(DISTINCT BIT_FIELD...) uses a tree to store keys;
which are constructed using a temporary table fields,
see Item_func_group_concat::setup().
As a) we don't store null bits in the tree where the bit fields store parts
of their data and b) there's no method to properly compare two table records
we've got problem.
Fix: convert BIT fields to INT in the temporary table used.
Bug#30982 CHAR(..USING..) can return a not-well-formed string
Bug#30986 Character set introducer followed by a HEX string can return bad result
check_well_formed_result moved to Item from Item_str_func
fixed Item_func_char::val_str for proper ucs symbols converting
added check for well formed strings for correct conversion of constants with underscore
charset
