and innodb
The 5.5 version of the patch.
The server doesn't restrict the data that can be inserted into integer columns
with explicitly specified length that's smaller than what the type can handle,
e.g. 1234 can be inserted into an INT(2) column just fine.
Thus, when calcualting the maximum width of expressions involving such
restricted integer columns we need to use the implicit maximum width of
the field instead of the explicitly speficied one.
Fixed the server to use the implicit maximum in such cases and made sure
the implicit maximum is addjusted the same way as the explicit one wrt
signedness.
Fixed several test case results (ctype_*.result, metadata.result and
type_ranges.result) to reflect the extended column widths.
Added a regression test case in distinct.test.
Note : this is the behavior preserving fix that makes 5.5 behave as 5.1 and
earlier. In the mysql trunk we'll add a insert time check for the explict
maximum size.
Certain fields in the protcol required a strict formatting. If
off bound values were sent to the server this could under some
circumstances lead to a crash on the Windows platform.
Attempts to assign value to a table column from trigger by using
NEW.column_name pseudo-variable might result in garbled data.
That happened when:
- the column had a BLOB-based type (e.g. TEXT)
and
- the value being assigned was retrieved from stored routine variable
of the same type.
The problem was that BLOB values were not copied correctly in this
case. Instead of doing a copy of a real value, the value's representation
in record buffer was copied. This representation is essentially a
pointer to a buffer associated with the virtual table for routine
variables where the real value is stored. Since this buffer got
freed once trigger was left or could have changed its contents when
new value was assigned to corresponding routine variable such a shallow
copying resulted in garbled data in NEW.colum_name column.
It worked in 5.1 due to a subtle bug in create_virtual_tmp_table():
- in 5.1 create_virtual_tmp_table() returned a table which
had db_low_byte_first == false.
- in 5.5 and up create_virtual_tmp_table() returns a table which
has db_low_byte_first == true.
Actually, db_low_byte_first == false only for ISAM storage engine,
which was deprecated and removed in 5.0.
Having db_low_byte_first == false led to getting false in the
complex condition for the 2nd "if" in field_conv(), which in turn
led to copy-blob-behavior as a fall-back strategy:
- to->table->s->db_low_byte_first was true (correct value)
- from->table->s->db_low_byte_first was false (incorrect value)
In 5.5 and up that condition is true, which means blob-values are
not copied.
(SUBSTRING inside a stored function works too slow).
The user-visible problem was that the server started to consume memory if a
stored-routine of some sort is executed subsequently. The memory was freed
only after the corresponding connection was closed.
Technically, the problem was that the memory needed for temporary string
conversions was allocated on the connection ("persistent") memory root,
instead of statement one.
The root cause of this problem was the incorrect patch for Bug 55744.
That patch wrongly fixed a crash in prepared-statement-mode introduced by
another patch. The patch for Bug 55744 used wrong condition to check if
prepared statement mode is active (or whether the connection-scoped or
statement-scoped memory root should be used). The thing is that for
prepared statements such conversions should be done in the connection
memory root, so that that the transformations of item-tree were correctly
remembered in the PREPARE-phase.
The fix is to use proper condition to detect prepared-statement-mode and
use proper memory root.
(SUBSTRING inside a stored function works too slow).
Background:
- THD classes derives from Query_arena, thus inherits the 'state'
attribute and related operations (is_stmt_prepare() & co).
- Although these operations are available in THD, they must not
be used. THD has its own attribute to point to the active
Query_arena -- stmt_arena.
- So, instead of using thd->is_stmt_prepare(),
thd->stmt_arena->is_stmt_prepare() must be used. This was the root
cause of Bug 60025.
This patch enforces the proper way of calling those operations.
is_stmt_prepare() & co are declared as private operations
in THD (thus, they are hidden from being called on THD instance).
The patch tries to minimize changes in 5.5.
Manual merge from mysql-5.1 into mysql-5.5.
Conflicts
=========
Text conflict in mysql-test/suite/rpl/t/rpl_row_until.test
Text conflict in sql/handler.h
Text conflict in storage/archive/ha_archive.cc
The query was re-written *after* we had tagged it with NON_AGG_FIELD_USED.
Remove the flag before continuing.
mysql-test/r/explain.result:
Update test case for Bug#48295.
mysql-test/r/subselect.result:
New test case.
mysql-test/t/explain.test:
Update test case for Bug#48295.
mysql-test/t/subselect.test:
New test case.
sql/item.cc:
Use accessor functions for non_agg_field_used/agg_func_used.
sql/item_subselect.cc:
Remove non_agg_field_used when we rewrite query '1 < some (...)' => '1 < max(...)'
sql/item_sum.cc:
Use accessor functions for non_agg_field_used/agg_func_used.
sql/mysql_priv.h:
Remove unused #defines.
sql/sql_lex.cc:
Initialize new member variables.
sql/sql_lex.h:
Replace full_group_by_flag with two boolean flags,
and itroduce accessors for manipulating them.
sql/sql_select.cc:
Use accessor functions for non_agg_field_used/agg_func_used.
The problem was that wrong structure of mysql.event was not detected and
the server continued to use wrongly-structured data.
The fix is to check the structure of mysql.event after opening before
any use. That makes operations with events more strict -- some operations
that might work before throw errors now. That seems to be Ok.
Another side-effect of the patch is that if mysql.event is corrupted,
unrelated DROP DATABASE statements issue an SQL warning about inability
to open mysql.event table.
The XPATH implementation was not handling correctly the XPATH
production #19
(http://www.w3.org/TR/1999/REC-xpath-19991116/#node-sets),
namely
PathExpr ::= | FilterExpr '/' RelativeLocationPath
| FilterExpr '//' RelativeLocationPath
It was lacking context for the RelativeLocationPath and it was just
ignoring the second slash instead of treating it as a different axis
specifier.
Fixed the above two problems and added a test case.
The partitioning engine checked the auto_increment column even if it was not to be written,
triggering a DBUG_ASSERT.
Fixed by checking if table->write_set for that column was set.
USING '..' ON WINDOWS
Backport of the fix to 5.0 (to be null-merged to 5.1).
Moved the test into the main test suite.
Made mysql-test-run.pl to not use symlinks for sdtdata as the symlinks
are now properly recognized by secure_file_priv.
Made sure the paths in load_file(), LOAD DATA and SELECT .. INTO OUTFILE
that are checked against secure_file_priv in a correct way similarly to 5.1
by the extended is_secure_file_path() backport before the comparison.
Added an extensive test with all the variants of upper/lower case,
slash/backslash and case sensitivity.
Added few comments to the code.
get_interval_value() was trying to parse the input string,
looking for leading '-' while skipping whitespace.
The macro my_isspace() does not work for utf16 character set,
since my_charset_utf16_general_ci.ctype == NULL.
Solution: convert input to ASCII before parsing.
mysql-test/r/ctype_utf16.result:
New test case.
mysql-test/t/ctype_utf16.test:
New test case.
sql/item_timefunc.cc:
Use val_string_ascii() rather than val_string()
so that we can safely use my_isspace() for skipping whitespace.
Partitions can have different ref_length (position data length).
Removed DBUG_ASSERT which crashed debug builds when using
MAX_ROWS on some partitions.
calc_daynr() function returns negative result
if malformed date with zero year and month is used.
Attempt to calculate week day on negative value
leads to crash. The fix is return NULL for
'W', 'a', 'w' specifiers if zero year and month is used.
Additional fix for calc_daynr():
--added assertion that result can not be negative
--return 0 if zero year and month is used
mysql-test/r/func_time.result:
test case
mysql-test/t/func_time.test:
test case
sql-common/my_time.c:
--added assertion that result can not be negative
--return 0 if zero year and month is used
sql/item_timefunc.cc:
eturn NULL for 'W', 'a', 'w' specifiers
if zero year and month is used.
Before sorting HAVING condition is split into two parts,
first part is a table related condition and the rest of is
HAVING part. Extraction of HAVING part does not take into account
the fact that some of conditions might be non-const but
have 'used_tables' == 0 (independent subqueries)
and because of that these conditions are cut off by
make_cond_for_table() function.
The fix is to use (table_map) 0 instead of used_tables in
third argument for make_cond_for_table() function.
It allows to extract elements which belong to sorted
table and in addition elements which are independend
subqueries.
mysql-test/r/having.result:
test case
mysql-test/t/having.test:
test case
sql/sql_select.cc:
The fix is to use (table_map) 0 instead of used_tables in
third argument for make_cond_for_table() function.
It allows to extract elements which belong to sorted
table and in addition elements which are independend
subqueries.
