The problem is that passing anything other than a integer to a limit
clause in a prepared statement would fail. This limitation was introduced
to avoid replication problems (e.g: replicating the statement with a
string argument would cause a parse failure in the slave).
The solution is to convert arguments to the limit clause to a integer
value and use this converted value when persisting the query to the log.
NAME_CONST('whatever', -1) * MAX(whatever) bombed since -1 was
not seen as constant, but as FUNCTION_UNARY_MINUS(constant)
while we are at the same time pretending it was a basic const
item. This confused the aggregate handlers in exciting ways.
We now make NAME_CONST() behave more consistently.
between 5.0 and 5.1.
The problem was that in the patch for Bug#11986 it was decided
to store original query in UTF8 encoding for the INFORMATION_SCHEMA.
This approach however turned out to be quite difficult to implement
properly. The main problem is to preserve the same IS-output after
dump/restore.
So, the fix is to rollback to the previous functionality, but also
to fix it to support multi-character-set-queries properly. The idea
is to generate INFORMATION_SCHEMA-query from the item-tree after
parsing view declaration. The IS-query should:
- be completely in UTF8;
- not contain character set introducers.
For more information, see WL4052.
breaks replication
NAME_CONST() didn't replicate constant character set and collation
correctly.
With this fix NAME_CONST() inherits collation from the value argument.
when executed in version 5
Zero fill is a field attribute only. So we can't always
propagate constants for zerofill fields : the values and
expression results don't have that flag.
Fixed by converting the const value to a string and
using that in const propagation when the context allows it.
Disable const propagation for fields with ZEROFILL flag in
all the other cases.
but not collation.
The problem here was that text literals in a view were always
dumped with character set introducer. That lead to loosing
collation information.
The fix is to dump character set introducer only if it was
in the original query. That is now possible because there
is no problem any more of loss of character set of string
literals in views -- after WL#4052 the view is dumped
in the original character set.
or trigger crashes server
Under some circumstances a combination of VIEWs, subselects with outer
references and PS/SP/triggers could lead to use of uninitialized memory
and server crash as a result.
Fixed by changing the code in Item_field::fix_fields() so that in cases
when the field is a VIEW reference, we first check whether the field
is also an outer reference, and mark it appropriately before returning.
The unsignedness of large integer user variables was not being
properly preserved when feeded to prepared statements. This was
happening because the unsigned flags wasn't being updated when
converting the user variable is converted to a parameter.
The solution is to copy the unsigned flag when converting the
user variable to a parameter and take the unsigned flag into
account when converting the integer to a string.
Two disjuncts containing equalities of the form key=const1 and key=const2 can
be merged into one if const1 is equal to const2. To check it the common
collation of the constants were used rather than the collation of the field key.
For example when the default collation of the constants was cases insensitive
while the collation of the field was case sensitive, then two or-ed equality
predicates key='b' and key='B' incorrectly were merged into one f='b'. As a
result ref access was used instead of range access and wrong result sets were
returned in many cases.
Fixed the problem by comparing constant in the or-ed predicate with collation of
the key field.
The name resolution for correlated subqueries and HAVING clauses
failed to distinguish which of two was being performed when there
was a reference to an outer aliased field.
Fixed by adding the condition that HAVING clause name resulotion
is being performed.
w/ Field_date instead of Field_newdate
Field_date was still used in temp table creation.
Fixed by using Field_newdate consistently throughout the server
except when reading tables defined with older MySQL version.
No test suite is possible because both Field_date and Field_newdate
return the same values in all the metadata calls.
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.
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.
Problem: passing a non-constant name to the NAME_CONST function results in a crash.
Fix: check the NAME_CONST name argument; return fake item type if we got
non-constant argument(s).
only on some occasions
Referencing an element from the SELECT list in a WHERE
clause is not permitted. The namespace of the WHERE
clause is the table columns only. This was not enforced
correctly when resolving outer references in sub-queries.
Fixed by not allowing references to aliases in a
sub-query in WHERE.
The columns in HAVING can reference the GROUP BY and
SELECT columns. There can be "table" prefixes when
referencing these columns. And these "table" prefixes
in HAVING use the table alias if available.
This means that table aliases are subject to the same
storage rules as table names and are dependent on
lower_case_table_names in the same way as the table
names are.
Fixed by :
1. Treating table aliases as table names
and make them lowercase when printing out the SQL
statement for view persistence.
2. Using case insensitive comparison for table
aliases when requested by lower_case_table_names
After adding an index the <VARBINARY> IN (SELECT <BINARY> ...)
clause returned a wrong result: the VARBINARY value was illegally padded
with zero bytes to the length of the BINARY column for the index search.
(<VARBINARY>, ...) IN (SELECT <BINARY>, ... ) clauses are affected too.
