tmptable needed
The function DEFAULT() works by modifying the the data buffer pointers (often
referred to as 'record' or 'table record') of its argument. This modification
is done during name resolution (fix_fields().) Unfortunately, the same
modification is done when creating a temporary table, because default values
need to propagate to the new table.
Fixed by skipping the pointer modification for fields that are arguments to
the DEFAULT function.
The retrieval of a charset by number was not
doing bounds checking before accessing the internal
character sets array.
Added checks for valid charset number.
Added asserts for valid charset number to some of
the internal functions.
Removed one superfluous check for charset_number 0
(since the all_charsets_array[0] is set to 0 anyway) for
uniformity.
Test suite added.
Problem: DATE_ADD() is a hybrid function and can return
DATE, DATETIME or VARCHAR data type depending on arguments.
In case of VARCHAR data type, DATE_ADD() reported "binary" character set,
which was wrong.
Fix: make DATE_ADD() return @character_set_connection in VARCHAR context.
@ mysql-test/include/ctype_numconv.inc
Adding tests
@ mysql-test/r/ctype_binary.result
Adding tests
@ mysql-test/r/ctype_cp1251.result
Adding tests
@ mysql-test/r/ctype_latin1.result
Adding tests
@ mysql-test/r/ctype_ucs.result
Adding tests
@ mysql-test/r/ctype_utf8.result
Adding tests
@ sql/item_strfunc.cc
- Moving code from Item_str_ascii_func::val_str() to
Item_str_func::val_str_from_val_str_ascii(), as
this code needs to be shared by Item_date_add_interval.
- Adding str2 parameter to be used as a buffer, instead of
using private ascii_buf member.
@ sql/item_strfunc.h
- Moving code from Item_str_ascii_func::val_str() to
Item_str_func::val_str_from_val_str_ascii()
- Removing "String *val_str_convert_from_ascii(String *str, String *ascii_buf)"
prototype as it was neither used nor declared.
@ sql/item_timefunc.h
- Overwriting parent's charset_for_protocol() method,
becase we need to behave differenlty in VARCHAR and DATE/DATETYPE context.
- Adding ascii_buf for conversion.
- Adding val_str_ascii() prototype.
- Adding val_str() which uses newly added
Item_str_func::val_str_from_val_str_ascii(),
passing ascii_buf as a conversion buffer.
Starting mysqld with defaults file without
extension cause segmentation fault
Bug occurs because fn_expand calls fn_format
with NULL as ext.
This is a backport of the patch from 5.6.
Patch solve this problem by using an empty
string as extension, and adding assertions
to fn_format that correct arguments are passed.
It also add a test tests several variations of
using non-existing defaults files.
Put descriptions of plugins into a separate file read by MTR
MTR itself has generalised code to read this and set env. variables
Removed the *SO variables, updated some tests accordingly
New commit: added optional list of plugin names for _LOAD variable
Also made changes for the new AUTH_* plugins
multiple columns in the partition key
ndb crash if duplicate columns in the partitioning key.
Backport from mysql-5.1-telco-7.0, see bug#53354.
Changed from case sensitive field name comparision
to non case sensitive too.
OPTIMIZE TABLE
OPTIMIZE TABLE for InnoDB tables is handled as recreate + analyze.
The triggered assert checked that an error had been reported if either
recreate or analyze failed. However the assert failed to take into
account that they could have failed because OPTIMIZE TABLE had been
victim of KILL QUERY, KILL CONNECTION or server shutdown.
This patch adjusts the assert to take this possibility into account.
The problem was only noticeable on debug versions of the server.
Test case added to innodb_mysql_sync.test.
and Order By
When having a UNION statement in a subquery, with no
referenced tables (or only a reference to the virtual
table 'dual'), the UNION did not allow an ORDER BY clause.
i.e:
SELECT(SELECT 1 AS a UNION
SELECT 0 AS a
ORDER BY a) AS b or
SELECT(SELECT 1 AS a FROM dual UNION
SELECT 0 as a
ORDER BY a) AS b
In addition, an ORDER BY / LIMIT clause was not accepted
in subqueries even for single SELECT statements with no
referenced tables (or with 'dual' as table reference)
i.e:
SELECT(SELECT 1 AS a ORDER BY a) AS b or
SELECT(SELECT 1 AS a FROM dual ORDER BY a) AS b
The fix was to allow an optional ORDER BY/LIMIT clause to
the grammar for these cases.
See also: Bug#57986
if embedded in a SELECT
An ORDER BY clause was bound to the incorrect
(sub-)statement when used in a UNION context.
In a query like:
SELECT * FROM a UNION SELECT * FROM b ORDER BY c
the result of SELECT * FROM b is sorted, and then
combined with a. The correct behaviour is that
the ORDER BY clause should be applied on the
final set. Similar behaviour was seen on LIMIT
clauses as well.
In a UNION statement, there will be a select_lex
object for each of the two selects, and a
select_lex_unit object that describes the UNION
itself. Similarly, the same behaviour was also
seen on derived tables.
The bug was caused by using a grammar rule for
ORDER BY and LIMIT that bound these elements
to thd->lex->current_select, which points to the
last of the two selects, instead of to the
fake_select_lex member of the master select_lex_unit
object.
- Second scenario checked:
Ensure via wait routines that the commit comes after the
processing of the statement which should get finally
the ER_LOCK_WAIT_TIMEOUT
--> This should prevent the current bug.
- First scenario checked:
Ensure via wait routines that the statement is already waiting
for getting the lock before the commit is given.
--> No effect on the current bug, but ensure that the right
scenario is reached.
- Take care that disconnects are finished before the test ends.
--> Reduce the potential to harm succeeding tests.
- "Mangle" the printout of the current default innodb_lock_wait_timeout value
--> No need to adjust the test in case the default gets changed in future.
- remove the superfluous file
- add an preemptive removal of the outfile before the
SELECT ... INTO OUTFILE ...
2. Remove an already disabled subtest
It's functionality is covered by tests in the suite funcs_1.
3. Adjust the formatting within some sub testcase to the formatting used
in all other sub testcases
This assert could be triggered if -1 was inserted into
an auto increment column by a statement writing more than
one row.
Unless explicitly given, an interval of auto increment values
is generated when a statement first needs an auto increment
value. The triggered assert checks that the auto increment
counter is equal to or higher than the lower bound of this
interval.
Generally, the auto increment counter starts at 1 and is
incremented by 1 each time it is used. However, inserting an
explicit value into the auto increment column, sets the auto
increment counter to this value + 1 if this value is higher
than the current value of the auto increment counter.
This bug was triggered if the explicit value was -1. Since the
value was converted to unsigned before any comparisons were made,
it was found to be higher than the current vale of the auto
increment counter and the counter was set to -1 + 1. This value
was below the reserved interval and caused the assert to be
triggered the next time the statement tried to write a row.
With the patch for Bug#39828, this bug is no longer repeatable.
Now, -1 + 1 is detected as an "overflow" which causes the auto
increment counter to be set to ULONGLONG_MAX. This avoids hitting
the assert for the next insert and causes a new interval of
auto increment values to be generated. This resolves the issue.
This patch therefore only contains a regression test and no code
changes. Test case added to auto_increment.test.
