When resolving references we need to take into consideration
the view "fields" and allow qualified access to them.
Fixed by extending the reference resolution to process view
fields correctly.
server crash.
The filesort implementation has an optimization for subquery execution which
consists of reusing previously allocated buffers. In particular the call to
the read_buffpek_from_file function might be skipped when a big enough buffer
for buffer descriptors (buffpeks) is already allocated. Beside allocating
memory for buffpeks this function fills allocated buffer with data read from
disk. Skipping it might led to using an arbitrary memory as fields' data and
finally to a crash.
Now the read_buffpek_from_file function is always called. It allocates
new buffer only when necessary, but always fill it with correct data.
to be compiled in
The problem was that on a statically built server an attempt to create
a UDF resulted in a different, but reasonable error ("Can't open shared
library" instead of "UDFs are unavailable with the --skip-grant-tables
option"), which caused a failure for the test case for bug #32020.
Fixed by moving the test case for bug #32020 from skip_grants.test to a
separate test to ensure that it is only run when the server is built
with support for dynamically loaded libraries.
at page 1024 with ucs2_bin
Inserting strings with a common prefix into a table with
characterset UCS2 corrupted the table.
An efficient search method was used, which compares end space
with ASCII blank. This doesn't work for character sets like UCS2,
which do not encode blank like ASCII does.
Use the less efficient search method _mi_seq_search()
for charsets with mbminlen > 1.
The checks in the test for bug #12480 were too wide and
made the test to depend on the procedures and triggers
present in the server.
Corrected the test to check only for the procedure and
trigger it creates.
In a union without braces, the order by at the end is applied to the
overall union. It therefore should not interfere with the individual
select parts of the union.
Fixed by changing our parser rules appropriately.
with null values
For queries containing GROUP_CONCAT(DISTINCT fields ORDER BY fields), there
was a limitation that the DISTINCT fields had to be the same as ORDER BY
fields, owing to the fact that one single sorted tree was used for keeping
track of tuples, ordering and uniqueness. Fixed by introducing a second
structure to handle uniqueness so that the original structure has only to
order the result.
subselects into account
It is forbidden to use the SELECT INTO construction inside UNION statements
unless on the last SELECT of the union. The parser records whether it
has seen INTO or not when parsing a UNION statement. But if the INTO was
legally used in an outer query, an error is thrown if UNION is seen in a
subquery. Fixed in 5.0 by remembering the nesting level of INTO tokens and
mitigate the error unless it collides with the UNION.
There were two problems when inferring the correct field types resulting from
UNION queries.
- If the type is NULL for all corresponding fields in the UNION, the resulting
type would be NULL, while the type is BINARY(0) if there is just a single
SELECT NULL.
- If one SELECT in the UNION uses a subselect, a temporary table is created
to represent the subselect, and the result type defaults to a STRING type,
hiding the fact that the type was unknown(just a NULL value).
Fixed by remembering whenever a field was created from a NULL value and pass
type NULL to the type coercion if that is the case, and creating a string field
as result of UNION only if the type would otherwise be NULL.
HOUR(), MINUTE(), ... returned spurious results when used on a DATE-cast.
This happened because DATE-cast object did not overload get_time() method
in superclass Item. The default method was inappropriate here and
misinterpreted the data.
Patch adds missing method; get_time() on DATE-casts now returns SQL-NULL
on NULL input, 0 otherwise. This coincides with the way DATE-columns
behave.
Also fixes similar bug in Date-Field now.
The problem was that when convert_constant_item is called for subqueries,
this happens when we already started executing the top-level query, and
the field argument of convert_constant_item pointed to a valid table row.
In turn convert_constant_item used the field buffer to compute the value
of its item argument. This copied the item's value into the field,
and made equalities with outer references always true.
The fix saves/restores the original field's value when it belongs to an
outer table.
Both arguments of the function NAME_CONST must be constant expressions.
This constraint is checked in the Item_name_const::fix_fields method.
Yet if the argument of the function was not a constant expression no
error message was reported. As a result the client hanged waiting for a
response.
Now the function Item_name_const::fix_fields reports an error message
when any of the additional context conditions imposed on the function
NAME_CONST is not satisfied.
The index (key_part_1, key_part-2) was erroneously considered as compatible
with the required ordering in the function test_test_if_order_by_key when
a query with an ORDER BY clause contained a condition of the form
key_part_1=const OR key_part_1 IS NULL
and the order list contained only key_part_2. This happened because the value
of the const_key_parts field in the KEYUSE structure was not formed correctly
for the keys that could be used for ref_or_null access.
This was fixed in the code of the update_ref_and_keys function.
The problem could not manifest itself for MyISAM databases because the
implementation of the keys_to_use_for_scanning() handler function always
returns an empty bitmap for the MyISAM engine.
When read_only option was enabled, a user without SUPER privilege could
perform CREATE DATABASE and DROP DATABASE operations.
This patch adds a check to make sure this isn't possible. It also attempts to
simplify the logic used to determine if relevant tables are updated,
making it more human readable.
