The flag alias_name_used was not set on for the outer references
in subqueries. It resulted in replacement of any outer reference
resolved against an alias for a full field name when the frm
representation of a view with a subquery was generated.
If the subquery and the outer query referenced the same table in
their from lists this replacement effectively changed the meaning
of the view and led to wrong results for selects from this view.
Modified several functions to ensure setting the right value of
the alias_name_used flag for outer references resolved against
aliases.
When the ORDER BY clause gets fixed it's allowed to search in the current
item_list in order to find aliased fields and expressions. This is ok for a
SELECT but wrong for an UPDATE statement. If the ORDER BY clause will
contain a non-existing field which is mentioned in the UPDATE set list
then the server will crash due to using of non-existing (0x0) field.
When an Item_field is getting fixed it's allowed to search item list for
aliased expressions and fields only for selects.
Several problems here :
1. The conversion to double of an hex string const item
was not taking into account the unsigned flag.
2. IN was not behaving in the same was way as comparisons
when performed over an INT/DATE/DATETIME/TIMESTAMP column
and a constant. The ordinary comparisons in that case
convert the constant to an INTEGER value and do int
comparisons. Fixed the IN to do the same.
3. IN is not taking into account the unsigned flag when
calculating <expr> IN (<int_const1>, <int_const2>, ...).
Extended the implementation of IN to store and process
the unsigned flag for its arguments.
If we compare two items A and B, with B being (a constant) of a
larger type, then A gets promoted to B's type for comparison if
it's a constant, function, or CAST() column, but B gets demoted
to A's type if A is a (not explicitly CAST()) column. This is
counter-intuitive and not mandated by the standard.
Disabling optimisation where it would be lossy so field value
will properly get promoted and compared as binary string (rather
than as integers).
to return NULL for non-NULL arguments.
This is not the case as it can return NULL
for invalid hexidecimal strings.
Fixed by setting the maybe_null flag.
results)
Before this fix, the function BENCHMARK() would fail to evaluate expressions
like "(select avg(a) from t1)" in debug builds (with an assert),
or would report a time of zero in non debug builds.
The root cause is that evaluation of DECIMAL_RESULT expressions was not
supported in Item_func_benchmark::val_int().
This has been fixed by this change.
INSERT DELAYED inserts garbage for BIT columns.
When delayed thread clones TABLE object, it didn't adjusted bit_ptr
to newly created record (though it correctly adjusts ptr and null_ptr).
This is fixed by correctly adjusting bit_ptr when performing a clone.
With this fix BIT values are stored correctly by INSERT DELAYED.
Bug N 15126 character_set_database is not replicated (LOAD DATA INFILE need it)
Positions of some binlog events were changed because of
additional logging of @@collation_database.
This patch fixes problem that LOAD DATA could use different
character sets when loading files on master and on slave sides:
- Adding replication of thd->variables.collation_database
- Adding optional character set clause into LOAD DATA
Note, the second way, with explicit CHARACTER SET clause
should be the recommended way to load data using an alternative
character set.
The old way, using "SET @@character_set_database=xxx" should be
gradually depricated.
Problem: DROP TRIGGER was not properly handled in combination
with slave filters, which made replication stop
Fix: loading table name before checking slave filters when
dropping a trigger.
- Use mysql_system_tables.sql to create MySQL system tables in
all places where we create them(mysql_install_db, mysql-test-run-pl
and mysql_fix_privilege_tables.sql)
Log messages from shell-scripts were put to var/log/<test id>.log
file. Now, this file is used by mysql-test-run.pl. So, move log
messages to var/log/<test id>.script.log.
Triggers in SBR mode."
BUG#14914 "SP: Uses of session variables in routines are not always
replicated"
BUG#25167 "Dupl. usage of user-variables in trigger/function is not
replicated correctly"
User-defined variables used inside of stored functions/triggers in
statements which did not update tables directly were not replicated.
We also had problems with replication of user-defined variables which
were used in triggers (or stored functions called from table-updating
statements) more than once.
This patch addresses the first issue by enabling logging of all
references to user-defined variables in triggers/stored functions
and not only references from table-updating statements.
The second issue stemmed from the fact that for user-defined
variables used from triggers or stored functions called from
table-updating statements we were writing binlog events for each
reference instead of only one event for the first reference.
This problem is already solved for stored functions called from
non-updating statements with help of "event unioning" mechanism.
So the patch simply extends this mechanism to the case affected.
It also fixes small problem in this mechanism which caused wrong
logging of references to user-variables in cases when non-updating
statement called several stored functions which used the same
variable and some of these function calls were omitted from binlog
as they were not updating any tables.
