Commit graph

1500 commits

Author SHA1 Message Date
Gleb Shchepa
dff10afb20 Bug #11827369: ASSERTION FAILED: !THD->LEX->CONTEXT_ANALYSIS_ONLY
Manual up-merge from 5.1 to 5.5.
2013-01-31 09:13:42 +04:00
Gleb Shchepa
19ea7c031d Bug #11827369: ASSERTION FAILED: !THD->LEX->CONTEXT_ANALYSIS_ONLY
Some queries with the "SELECT ... FROM DUAL" nested subqueries
failed with an assertion on debug builds.
Non-debug builds were not affected.

There were a few different issues with similar assertion
failures on different queries:

1. The first problem was related to the incomplete propagation
of the "non-constant" item status from underlying subquery
items to the outer item tree: in some cases non-constants were
interpreted as constants and evaluated at the preparation stage
(val_int() calls withing fix_fields() etc).

Thus, the default implementation of Item_ref::const_item() from
the Item parent class didn't take into account the "const_item"
status of the referenced item tree -- it used the insufficient
"used_tables() == 0" check instead. This worked in most cases
since our "non-constant" functions like RAND() and SLEEP() set
the RAND_TABLE_BIT in the used table map, so they aren't
non-constant from Item_ref's "point of view". However, the
"SELECT ... FROM DUAL" subquery may have an empty map of used
tables, but at the same time subqueries are never "constant" at
the context analysis stage (preparation, view creation etc).
So, the non-contantness of such subqueries was missed.

Fix: the Item_ref::const_item() function has been overloaded to
take into account both (*ref)->const_item() status and tricky
Item_ref::used_tables() return values, since the only
(*ref)->const_item() call is not enough there.

2. In some cases instead of the const_item() call we check a
value of the Item::with_subselect field to recognize items
with nested subqueries. However, the Item_ref class didn't
propagate this value from the referenced item tree.

Fix: Item::has_subquery() and Item_ref::has_subquery()
functions have been backported from 5.6. All direct
references to the with_subselect fields of nested items have
been with the has_subquery() function call.

3. The Item_func_regex class didn't propagate with_subselect
as well, since it overloads the Item_func::fix_fields()
function with insufficient fix_fields() implementation.

Fix: the Item_func_regex::fix_fields() function has been
modified to gather "constant" statuses from inner items.

4. The Item_func_isnull::update_used_tables() function has
a special branch for the underlying item where the maybe_null
value is false: in this case it marks the Item_func_isnull
as a "const_item" and sets the cached_value to false.
However, the Item_func_isnull::val_int() was not in sync with
update_used_tables(): it didn't take into account neither
const_item_cache nor cached_value for the case of
"args[0]->maybe_null == false optimization".
As far as such an Item_func_isnull has "const_item() == true",
it's ok to call Item_func_isnull::val_int() etc from outer
items on preparation stage. In this case the server tried to
call Item_func_isnull::args[0]->isnull(), and if the args[0]
item contained a nested not-nullable subquery, it failed
with an assertion.

Fix: take the value of Item_func_isnull::const_item_cache into
account in the val_int() function.

5. The auxiliary Item_is_not_null_test class has a similar
optimization in the update_used_tables() function as the
Item_func_isnull class has, and the same issue in the val_int()
function.
In addition to that the Item_is_not_null_test::update_used_tables()
doesn't update the const_item_cache value, so the "maybe_null"
optimization is useless there. Thus, we missed some optimizations
of cases like these (before and after the fix):
  <  <is_not_null_test>(a),
  ---
  >  <cache>(<is_not_null_test>(a)),
or
  < having (<is_not_null_test>(a) and <is_not_null_test>(a))
  ---
  > having 1
etc.

Fix: update Item_is_not_null_test::const_item_cache in
update_used_tables() and take in into account in val_int().
2013-01-23 09:51:50 +04:00
Sergey Glukhov
51672ec2d4 5.1 -> 5.5 merge 2012-08-09 15:50:29 +04:00
Sergey Glukhov
2f30b34095 Bug #14409015 MEMORY LEAK WHEN REFERENCING OUTER FIELD IN HAVING
When resolving outer fields, Item_field::fix_outer_fields()
creates new Item_refs for each execution of a prepared statement, so
these must be allocated in the runtime memroot. The memroot switching
before resolving JOIN::having causes these to be allocated in the
statement root, leaking memory for each PS execution.


sql/item_subselect.cc:
  addon, fix for 11829691, item could be created in
  runtime memroot, so we need to use real_item instead.
2012-08-09 15:34:52 +04:00
Norvald H. Ryeng
fc3c4e70c2 Merge 5.1->5.5. 2012-06-18 09:45:42 +02:00
Norvald H. Ryeng
cac1cd88ab Bug#13003736 CRASH IN ITEM_REF::WALK WITH SUBQUERIES
Problem: Some queries with subqueries and a HAVING clause that
consists only of a column not in the select or grouping lists causes
the server to crash.

During parsing, an Item_ref is constructed for the HAVING column. The
name of the column is resolved when JOIN::prepare calls fix_fields()
on its having clause. Since the column is not mentioned in the select
or grouping lists, a ref pointer is not found and a new Item_field is
created instead. The Item_ref is replaced by the Item_field in the
tree of HAVING clauses. Since the tree consists only of this item, the
pointer that is updated is JOIN::having. However,
st_select_lex::having still points to the Item_ref as the root of the
tree of HAVING clauses.

The bug is triggered when doing filesort for create_sort_index(). When
find_all_keys() calls select->cond->walk() it eventually reaches
Item_subselect::walk() where it continues to walk the having clauses
from lex->having. This means that it finds the Item_ref instead of the
new Item_field, and Item_ref::walk() tries to dereference the ref
pointer, which is still null.

The crash is reproducible only in 5.5, but the problem lies latent in
5.1 and trunk as well.

Fix: After calling fix_fields on the having clause in JOIN::prepare(),
set select_lex::having to point to the same item as JOIN::having.

This patch also fixes a bug in 5.1 and 5.5 that is triggered if the
query is executed as a prepared statement. The Item_field is created
in the runtime arena when the query is prepared, and the pointer to
the item is saved by st_select_lex::fix_prepare_information() and
brought back as a dangling pointer when the query is executed, after
the runtime arena has been reclaimed.

Fix: Backport fix from trunk that switches to the permanent arena
before calling Item_ref::fix_fields() in JOIN::prepare().


sql/item.cc:
  Set context when creating Item_field.
sql/sql_select.cc:
  Switch to permanent arena and update select_lex->having.
2012-06-18 09:20:12 +02:00
Tor Didriksen
13053fbe54 Bug#13721076 CRASH WITH TIME TYPE/TIMESTAMP() AND WARNINGS IN SUBQUERY
The table contains one time value: '00:00:32'
This value is converted to timestamp by a subquery.

In convert_constant_item we call (*item)->is_null()
which triggers execution of the Item_singlerow_subselect subquery,
and the string "0000-00-00 00:00:32" is cached
by Item_cache_datetime.
We continue execution and call update_null_value, which calls val_int()
on the cached item, which converts the time value to ((longlong) 32)
Then we continue to do (*item)->save_in_field()
which ends up in Item_cache_datetime::val_str() which fails,
since (32 < 101) in number_to_datetime, and val_str() returns NULL.

Item_singlerow_subselect::val_str isnt prepared for this:
if exec() succeeds, and return !null_value, then val_str()
*must* succeed.

Solution: refuse to cache strings like "0000-00-00 00:00:32"
in Item_cache_datetime::cache_value, and return NULL instead.

This is similar to the solution for 
Bug#11766860 - 60085: CRASH IN ITEM::SAVE_IN_FIELD() WITH TIME DATA TYPE

This patch is for 5.5 only.
The issue is not present after WL#946, since a time value
will be converted to a proper timestamp, with the current date
rather than "0000-00-00"


mysql-test/r/subselect.result:
  New test case.
mysql-test/t/subselect.test:
  New test case.
sql/item.cc:
  Verify proper date format before caching timestamps.
sql/item_timefunc.cc:
  Use named constant for readability.
2012-03-14 13:25:14 +01:00
Norvald H. Ryeng
1a2e4afe35 Merge 5.1 => 5.5. 2012-03-12 09:24:59 +01:00
Norvald H. Ryeng
ad031d5110 Bug#13031606 VALUES() IN A SELECT STATEMENT CRASHES SERVER
Problem: Grouping results by VALUES(alias for string literal) causes
the server to crash.

Item_insert_values is not constructed to handle other types of
arguments than field and reference to field. In this case, the
argument is an Item_string, and this causes
Item_insert_values::fix_fields() to crash.

Fix: Issue an error message when the argument to Item_insert_values is
not a field or a reference to a field.

This is slightly in breach with documentation, which states that
VALUES should return NULL, but the error message is only issued in
cases where the server otherwise would crash, so there is no change in
behavior for queries that already work. Future versions will restrict
syntax so that using VALUES in this way is illegal.


mysql-test/r/errors.result:
  Add test case for bug #13031606.
mysql-test/t/errors.test:
  Add test case for bug #13031606.
sql/item.cc:
  Issue error message if argument is not field or reference to field.
2012-03-12 08:56:56 +01:00
Praveenkumar Hulakund
c22c9270fb Bug#12601974 - STORED PROCEDURE SQL_MODE=NO_BACKSLASH_ESCAPES IGNORED AND BREAKS REPLICATION
Analysis:
========================
sql_mode "NO_BACKSLASH_ESCAPES": When user want to use backslash as character input,
instead of escape character in a string literal then sql_mode can be set to 
"NO_BACKSLASH_ESCAPES". With this mode enabled, backslash becomes an ordinary 
character like any other. 

SQL_MODE set applies to the current client session. And while creating the stored 
procedure, MySQL stores the current sql_mode and always executes the stored 
procedure in sql_mode stored with the Procedure, regardless of the server SQL 
mode in effect when the routine is invoked.  

In the scenario (for which bug is reported), the routine is created with 
sql_mode=NO_BACKSLASH_ESCAPES. And routine is executed with the invoker sql_mode
is "" (NOT SET) by executing statement "call testp('Axel\'s')".
Since invoker sql_mode is "" (NOT_SET), the '\' in 'Axel\'s'(argument to function)
is considered as escape character and column "a" (of table "t1") values are 
updated with "Axel's". The binary log generated for above update operation is as below,

  set sql_mode=XXXXXX (for no_backslash_escapes)
  update test.t1 set a= NAME_CONST('var',_latin1'Axel\'s' COLLATE 'latin1_swedish_ci');

While logging stored procedure statements, the local variables (params) used in
statements are replaced with the NAME_CONST(var_name, var_value) (Internal function) 
(http://dev.mysql.com/doc/refman/5.6/en/miscellaneous-functions.html#function_name-const)

On slave, these logs are applied. NAME_CONST is parsed to get the variable and its
value. Since, stored procedure is created with sql_mode="NO_BACKSLASH_ESCAPES", the sql_mode
is also logged in. So that at slave this sql_mode is set before executing the statements
of routine.  So at slave, sql_mode is set to "NO_BACKSLASH_ESCAPES" and then while
parsing NAME_CONST of string variable, '\' is considered as NON ESCAPE character
and parsing reported error for "'" (as we have only one "'" no backslash). 

At slave, parsing was proper with sql_mode "NO_BACKSLASH_ESCAPES".
But above error reported while writing bin log, "'" (of Axel's) is escaped with
"\" character. Actually, all special characters (n, r, ', ", \, 0...) are escaped
while writing NAME_CONST for string variable(param, local variable) in bin log 
Airrespective of "NO_BACKSLASH_ESCAPES" sql_mode. So, basically, the problem is 
that logging string parameter does not take into account sql_mode value.

Fix:
========================
So when sql_mode is set to "NO_BACKSLASH_ESCAPES", escaping  characters as 
(n, r, ', ", \, 0...) should be avoided. To do so, added a check to not to
escape such characters while writing NAME_CONST for string variables in bin 
log. 
And when sql_mode is set to NO_BACKSLASH_ESCAPES, quote character "'" is
represented as ''.
http://dev.mysql.com/doc/refman/5.6/en/string-literals.html (There are several 
ways to include quote characters within a string: )



mysql-test/r/sql_mode.result:
  Added test case for Bug#12601974.
mysql-test/suite/binlog/r/binlog_sql_mode.result:
  Appended result of test cases added for Bug#12601974.
mysql-test/suite/binlog/t/binlog_sql_mode.test:
  Added test case for Bug#12601974.
mysql-test/t/sql_mode.test:
  Appended result of test cases added for Bug#12601974.
2012-02-29 12:23:15 +05:30
Praveenkumar Hulakund
a0b46059ee Merge from 5.1 to 5.5 2012-02-29 14:15:15 +05:30
MySQL Build Team
7a35cb9150 Updated/added copyright headers 2012-02-16 10:48:16 +01:00
Kent Boortz
6a003dd8ef Updated/added copyright headers 2012-02-15 17:21:38 +01:00
MySQL Build Team
7177a2b9d7 Updated/added copyright headers 2012-02-15 17:13:47 +01:00
Guilhem Bichot
95646db77b merge from 5.1 2012-01-26 10:38:28 +01:00
Guilhem Bichot
9e0b69c0b7 Fixes for:
BUG#13519696 - 62940: SELECT RESULTS VARY WITH VERSION AND
WITH/WITHOUT INDEX RANGE SCAN
BUG#13453382 - REGRESSION SINCE 5.1.39, RANGE OPTIMIZER WRONG
RESULTS WITH DECIMAL CONVERSION
BUG#13463488 - 63437: CHAR & BETWEEN WITH INDEX RETURNS WRONG
RESULT AFTER MYSQL 5.1.
Those are all cases where the range optimizer got it wrong
with > and >=.

mysql-test/r/range.result:
  Without the code fix for DECIMAL, "select count(val) from t2 where val > 0.1155"
  (which uses a range scan) returned 127 instead of 128);
  Moreover, both
  select * from t1 force  index (primary) where a=1 and c>= 2.9;
  and
  select * from t1 force  index (primary) where a=1 and c> 2.9;
  would miss "1	1	3".
  Without the code fix for strings, both
  SELECT * FROM t1 WHERE F1 >= 'A    ';
  and
  SELECT * FROM t1 WHERE F1 BETWEEN 'A    ' AND 'AAAAA';
  would miss "A	A	A".
sql/item.cc:
  Preamble to the explanations below: opt_range.cc:get_mm_leaf() does
  this (this is not changed by the patch): changes
  column > value
  to
  column OP V
  where:
  * V is what is in "column" after we stored "value" in it
  (such store operation may have done rounding...)
  * OP is > or >=, depending on what's correct.
  For example, if c is an INT column,
  c > 2.9 is changed to
  c OP 3
  where OP is >= ('>' would not be correct).
  The bugs below are cases where we chose OP wrongly.
  Note that such transformations are visible in the optimizer trace.
  
  1) Fix for STRING. In the scenario with CHAR(5) in range.test, this happens,
  in get_mm_tree(), for the condition F1>='A    ':
  * value->save_in_field_no_warnings(field, 1) wants to store the right argument
  (named 'item') into the CHAR(5) field; this stores 'A    ' (the item's value)
  padded with spaces (which changes nothing: still 'A    ')
  * we come to
    case Item_func::GE_FUNC:
      /* Don't use open ranges for partial key_segments */
      if ((!(key_part->flag & HA_PART_KEY_SEG)) &&
          (stored_field_cmp_to_item(param->thd, field, value) < 0))
        tree->min_flag= NEAR_MIN;
      tree->max_flag=NO_MAX_RANGE;
  What this wants to do is: if the field's value is strictly smaller
  than the item's, then ">=" can be changed to ">" (this is an optimization,
  it can help pruning one useless partition).
  * stored_field_cmp_to_item() is called; it compares the field's
  and item's values: the item's value (Item_string::val_str()) is
  'A    ') and the field's value (Field_string::val_str()) is
  'A' (yes val_str() removes end spaces unless sql_mode='PAD_CHAR_TO_FULL_LENGTH');
  and the comparison is done with stringcmp() which considers
  end spaces as relevant; as end spaces differ, function returns a
  negative number, and ">='A    '" becomes ">'A'" (i.e. the NEAR_MIN
  flag is turned on).
  During execution the index range scan code will search for "A", find
  a match, but exclude it (because of ">"), wrongly.
  The badness is the string comparison done by stored_field_cmp_to_item():
  we use the reply of this function to determine where the index search
  should start, so it should do comparison like index search does
  comparisons; index search comparisons are ha_key_cmp() which uses
  a collation-aware comparison (in our case, my_strnncollsp_simple(),
  which ignores end spaces); so stored_field_cmp_to_item()
  needs to do the same. When this is fixed, condition becomes
  ">='A    '".
  
  2) Fix for DECIMAL: just like in other comparisons in stored_field_cmp_to_item(),
  we must first pass the field and then the item; otherwise expectations
  on what <0 and >0 mean (inferiority, superiority) get violated.
  In the test in range.test about c>2.9: c is an INT column, so 2.9
  gets stored as 3, then stored_field_cmp_to_item() compares 3
  and 2.9; because of the wrong order of arguments passed
  to my_decimal_cmp(), range optimizer
  thinks that 3 is < 2.9 and thus changes "c> 2.9" to "c> 3".
  After fixing the order, it changes to the correct "c>= 3".
  In the test in range.inc for val > 0.1155, it was changed to
  val > 0.116, now it is changed to val >= 0.116.
2012-01-26 10:25:23 +01:00
Tor Didriksen
c796415943 Bug#13463415 followup: compensate for compiler bug 2012-01-25 16:05:27 +01:00
Alexander Barkov
1522923949 BUG#13354387 - CRASH IN IN MY_DECIMAL::OPERATOR FOR VIEW AND FUNCTION UNIX_TIME
Fixing the 5.5 part (the 5.6 part will go in a separate commit soon).

Problem:
  Item_direct_ref::get_date() incorrectly calculated its "null_value",
  which made UNIX_TIMESTAMP(view_column) incorrectly return NULL
  for a NOT NULL view_column.

Fix:
  Make Item_direct_ref::get_date() calculate null_value
  in the similar way with the other methods 
  (val_real,val_str,val_int,val_decimal):
  copy null_value from the referenced Item.

modified:
  mysql-test/r/func_time.result
  mysql-test/t/func_time.test
  sql/item.cc
2012-01-12 13:02:51 +04:00
Tor Didriksen
0cd9228124 Bug#13013970 MORE CRASHES IN FIELD_BLOB::GET_KEY_IMAGE
The predicate is re-written from
((`test`.`g1`.`a` = geometryfromtext('')) or ...
to
((`test`.`g1`.`a` = <cache>(geometryfromtext(''))) or ...

The range optimizer calls save_in_field_no_warnings, in order to fetch keys.
save_in_field_no_warnings returns 0 because of the cache wrapper,
and get_mm_leaf() proceeded to call Field_blob::get_key_image() 
which accesses un-initialized data.




mysql-test/r/gis.result:
  New test case.
mysql-test/t/gis.test:
  New test case.
sql/item.cc:
  If we have cached a null_value, then verify that the Field can accept it.
2011-12-05 15:42:45 +01:00
Sunanda Menon
af6ddeca48 Merge from mysql-5.0.94-release 2011-07-06 11:36:39 +02:00
unknown
7d605ec45f Merge from mysql-5.5.14-release 2011-07-06 01:13:50 +02:00
Karen Langford
f6398a86dd Merge from mysql-5.1.58-release 2011-07-06 00:56:51 +02:00
Kent Boortz
027b5f1ed4 Updated/added copyright headers 2011-07-03 17:47:37 +02:00
Kent Boortz
68f00a5686 Updated/added copyright headers 2011-06-30 17:37:13 +02:00
Kent Boortz
44135d4725 Updated/added copyright headers 2011-06-30 17:31:31 +02:00
Georgi Kodinov
54729bbc60 merged mysql-5.5->mysql-5.5-security 2011-06-06 16:17:58 +03:00
Kent Boortz
789aa8c485 Updated/added copyright headers 2011-07-04 01:25:49 +02:00
Kent Boortz
02e07e3b51 Updated/added copyright headers 2011-06-30 17:46:53 +02:00
Georgi Kodinov
5a2ccea2e7 Bug #11744875: 4082: integer lengths cause truncation with distinct concat
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.
2011-05-11 14:11:57 +03:00
Georgi Kodinov
c4c808d606 weave merge of mysql-5.5->mysql-5.5-security 2011-05-10 17:20:26 +03:00
Alexander Nozdrin
8f79579925 Patch for Bug#12362125 (SP INOUT HANDLING IS BROKEN FOR TEXT TYPE).
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.
2011-05-09 12:29:23 +04:00
Alexander Nozdrin
acbe82380e Patch for Bug#11848763 / 60025
(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.
2011-05-06 15:41:24 +04:00
Alexander Nozdrin
52efe3e00d Preliminary patch for Bug#11848763 / 60025
(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.
2011-05-06 15:39:40 +04:00
Tor Didriksen
6848f6c0d6 merge 5.1 => 5.5 : Bug#12329653 2011-05-05 08:13:22 +02:00
Tor Didriksen
e257fb3319 merge 5.0 => 5.1 : Bug#12329653 2011-05-04 17:12:45 +02:00
Tor Didriksen
1cf483aa58 Bug#12329653 - EXPLAIN, UNION, PREPARED STATEMENT, CRASH, SQL_FULL_GROUP_BY
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.
2011-05-04 16:18:21 +02:00
Alexander Barkov
a1c762b9df Bug#11926811 / Bug#60625 Illegal mix of collations
Problem: comparison of a DATETIME sp variable and NOW()
led to Illegal mix of collations error when 
character_set_connection=utf8.
Introduced by "WL#2649 Number-to-string conversions".

Error happened in Arg_comparator::set_compare_func(),
because the first argument was errouneously converted to utf8,
while the second argument was not.

Fix: separate agg_arg_charsets_for_comparison() into two functions:

- agg_arg_charsets_for_comparison() - for pure comparison,
  when we don't need to return any string result and therefore
  don't need to convert arguments to @@character_set_connection:
    SELECT a = b;

- agg_arg_charsets_for_string_results_with_comparison() - when
  we need to return a string result, but we also need to do
  comparison internally: SELECT REPLACE(a,b,c)
  If all arguments are numbers:
    SELECT REPLACE(123,2,3) -> 133
  we convert arguments to @@character_set_connection.


  @ mysql-test/include/ctype_numconv.inc
  @ mysql-test/r/ctype_binary.result
  @ mysql-test/r/ctype_cp1251.result
  @ mysql-test/r/ctype_latin1.result
  @ mysql-test/r/ctype_ucs.result
  @ mysql-test/r/ctype_utf8.result
  Adding tests

  @ sql/item.cc
  @ sql/item.h
  @ sql/item_func.cc
  @ sql/item_func.h
  @ sql/item_strfunc.cc

  Introducing and using new function
   agg_item_charsets_for_string_result_with_comparison() and
  its Item_func wrapper agg_arg_charsets_for_string_result_with_comparison().
2011-04-08 17:15:23 +04:00
Gleb Shchepa
b2fee393b0 manual merge 5.1-->5.5 (bug 11829681) 2011-04-08 12:09:24 +04:00
Gleb Shchepa
a77bc59896 Bug #11829681 - 60295: ERROR 1356 ON VIEW THAT EXECUTES FINE AS A QUERY
Select from a view with the underlying HAVING clause failed with a
message: "1356: View '...' references invalid table(s) or column(s)
or function(s) or definer/invoker of view lack rights to use them"

The bug is a regression of the fix for bug 11750328 - 40825 (similar
case, but the HAVING cause references an aliased field).
In the old fix for bug 40825 the Item_field::name_length value has
been used in place of the real length of Item_field::name. However,
in some cases Item_field::name_length is not in sync with the
actual name length (TODO: combine name and name_length into a
solid String field).

The Item_ref::print() method has been modified to calculate actual
name length every time.


mysql-test/r/view.result:
  Test case for bug #11829681
mysql-test/t/view.test:
  Test case for bug #11829681
sql/item.cc:
  Bug #11829681 - 60295: ERROR 1356 ON VIEW THAT EXECUTES FINE AS A QUERY
  
  The Item_ref::print() method has been modified to calculate actual
  name length every time.
sql/item.h:
  Minor commentary.
2011-04-08 12:05:20 +04:00
Gleb Shchepa
7ba944c465 auto-merge 5.1-->5.5 (bug 11766094) 2011-04-02 23:41:10 +04:00
Gleb Shchepa
7aa81e2a02 Bug #11766094 - 59132: MIN() AND MAX() REMOVE UNSIGNEDNESS
In the string context the MIN() and MAX() functions don't take
into account the unsignedness of the UNSIGNED BIGINT argument
column.

I.e.:
        CREATE TABLE t1 (a BIGINT UNSIGNED);
        INSERT INTO t1 VALUES (18446668621106209655);
        SELECT CONCAT(MAX(a)) FROM t1;

returns -75452603341961.


mysql-test/r/func_group.result:
  Test case for bug #11766094.
mysql-test/t/func_group.test:
  Test case for bug #11766094.
sql/item.cc:
  Bug #11766094 - 59132: MIN() AND MAX() REMOVE UNSIGNEDNESS
  
  The Item_cache_int::val_str() method has been modified to
  take into account the unsigned_flag value when converting
  data to string.
2011-03-31 22:59:11 +04:00
Sergey Glukhov
abbe33eb92 5.1 -> 5.5 merge 2011-03-30 11:25:49 +04:00
Sergey Glukhov
a7d383cbb8 Bug#11766124 59164: VALGRIND: UNINITIALIZED VALUE IN NUMBER_TO_DATETIME
Valgrind warning happens due to missing NULL value check in
Item::get_date. The fix is to add this check.


mysql-test/r/func_time.result:
  test case
mysql-test/t/func_time.test:
  test case
sql/item.cc:
  added check for NULL value
2011-03-30 11:08:35 +04:00
unknown
753c406994 Merge from mysql-5.5.10-release 2011-03-16 15:11:20 +01:00
Dmitry Shulga
feb6d22328 Manual merge from mysql-5.1 for Bug#11764168 (56976: Severe denial
of service in prepared statements).

sql/sql_prepare.cc:
  At mysql_stmt_get_longdata(): instead of pushing an internal
  error handler (as done in 5.1-tree) we save, set and restore
  the statement's diagnostics area and warning info.
2011-03-15 18:57:36 +06:00
Dmitry Shulga
9320dca994 Fixed Bug#11764168 "56976: SEVERE DENIAL OF SERVICE IN PREPARED STATEMENTS".
The problem was that server didn't check resulting size of prepared
statement argument which was set using mysql_send_long_data() API.
By calling mysql_send_long_data() several times it was possible
to create overly big string and thus force server to allocate
memory for it. There was no way to limit this allocation.

The solution is to add check for size of result string against
value of max_long_data_size start-up parameter. When intermediate
string exceeds max_long_data_size value an appropriate error message
is emitted.

We can't use existing max_allowed_packet parameter for this purpose
since its value is limited by 1GB and therefore using it as a limit
for data set through mysql_send_long_data() API would have been an
incompatible change. Newly introduced max_long_data_size parameter
gets value from max_allowed_packet parameter unless its value is
specified explicitly. This new parameter is marked as deprecated
and will be eventually replaced by max_allowed_packet parameter.
Value of max_long_data_size parameter can be set only at server
startup.


mysql-test/t/variables.test:
  Added checking for new start-up parameter max_long_data_size.
sql/item.cc:
  Added call to my_message() when accumulated string exceeds
  max_long_data_size value. my_message() calls error handler
  that was installed in mysql_stmt_get_longdata before call
  to Item_param::set_longdata.
  
  The error handler then sets state, last_error and last_errno
  fields for current statement to values which correspond to
  error which was caught.
sql/mysql_priv.h:
  Added max_long_data_size variable declaration.
sql/mysqld.cc:
  Added support for start-up parameter 'max_long_data_size'.
  This parameter limits size of data which can be sent from
  client to server using mysql_send_long_data() API.
sql/set_var.cc:
  Added variable 'max_long_data_size' into list of variables
  displayed by command 'show variables'.
sql/sql_prepare.cc:
  Added error handler class Set_longdata_error_handler.
  This handler is used to catch any errors that can be
  generated during execution of Item_param::set_longdata().
  
  Source code snippet that makes checking for statement's state 
  during statement execution is moved from Prepared_statement::execute()
  to Prepared_statement::execute_loop() in order not to call
  set_parameters() when statement has failed during
  set_long_data() execution. If this hadn't been done
  the call to set_parameters() would have failed.
tests/mysql_client_test.c:
  A testcase for the bug #56976 was added.
2011-03-15 17:36:12 +06:00
Alexander Barkov
b326b9a3a0 Bug#11764503 (Bug#57341) Query in EXPLAIN EXTENDED shows wrong characters
@ mysql-test/r/ctype_latin1.result
  @ mysql-test/r/ctype_utf8.result
  @ mysql-test/t/ctype_latin1.test
  @ mysql-test/t/ctype_utf8.test
  Adding tests

  @ sql/mysqld.h
  @ sql/item.cc
  @ sql/sql_parse.cc
  @ sql/sql_view.cc

  Refactoring (thanks to Guilhem for the idea):

  Item_string::print() was hard to understand because of the different
  QT_ constants: in "query_type==QT_x", QT_x is explicitely included
  but the other two QT_ are implicitely excluded. The combinations
  with '||' and '&&' make this even harder.
  - logic is now more "explicit" by changing QT_ constants to a bitmap of flags:
    QT_ORDINARY: no change,
    QT_IS -> QT_TO_SYSTEM_CHARSET | QT_WITHOUT_INTRODUCERS,
    QT_EXPLAIN -> QT_TO_SYSTEM_CHARSET
    (QT_EXPLAIN was introduced in the first version of the Bug#57341 patch)
  - Item_string::print() is rewritten using those flags

  Bugfix itself:

  When QT_TO_SYSTEM_CHARSET is used alone (with no QT_WITHOUT_INTRODUCERS),
  we print string literals as follows:

  - display introducers if they were in the original query
  - print ASCII characters as is
  - print non-ASCII characters using hex-escape
  Note: as "EXPLAIN" output is only for human readability purposes
  and does not need to be a pasrable SQL, so using hex-escape is Ok.
  ErrConvString class perfectly suites for hex escaping purposes.
2011-03-04 18:43:28 +03:00
Tor Didriksen
08c8d21f2b Bug #11766860 - 60085: CRASH IN ITEM::SAVE_IN_FIELD() WITH TIME DATA TYPE
This assumption in Item_cache_datetime::cache_value_int
was wrong:
-  /* Assume here that the underlying item will do correct conversion.*/
-  int_value= example->val_int_result();


mysql-test/r/subselect_innodb.result:
  New test case.
mysql-test/t/subselect_innodb.test:
  New test case.
sql/item.cc:
  In Item_cache_datetime::cache_value_int()
   - call get_time() or get_date() depending on desired type
   - convert the returned MYSQL_TIME value to longlong depending on desired type
sql/item.h:
  The cached int_value in Item_cache_datetime should not be unsigned:
   - it is used mostly in signed context
   - it can actually have negative value (for TIME data type)
sql/item_cmpfunc.cc:
  Add comment on Bug#59685
sql/item_subselect.cc:
  Add some DBUG_TRACE for easier bug-hunting.
2011-02-17 13:41:25 +01:00
Evgeny Potemkin
0a80d5bd0d Bug#59330: Incorrect result when comparing an aggregate function with
TIMESTAMP.

Item_cache::get_cache wasn't treating TIMESTAMP as a DATETIME value thus
returning string cache for items with TIMESTAMP type. This led to incorrect
TIMESTAMP -> INT conversion and to a wrong query result.

Fixed by using Item::is_datetime function to check for DATETIME type group.


mysql-test/r/type_timestamp.result:
  Added a test case for the bug#59330.
mysql-test/t/type_timestamp.test:
  Added a test case for the bug#59330.
sql/item.cc:
  Bug#59330: Incorrect result when comparing an aggregate function with
  TIMESTAMP.
  Item_cache::get_cache now uses is_datetime member function to detect DATETIME
  type group.
2011-01-12 15:58:47 +03:00
Sergey Glukhov
41f17a8707 5.1-bugteam->5.5-bugteam merge 2010-12-21 14:50:03 +03:00