Commit graph

1379 commits

Author SHA1 Message Date
Alexey Kopytov
84766b060a Manual merge from mysql-5.1-bugteam to mysql-trunk-merge.
Conflicts:

Text conflict in scripts/Makefile.am
Text conflict in sql/share/Makefile.am
2010-02-26 16:06:31 +03:00
Gleb Shchepa
936ed6ca86 Bug #45360: wrong results
Propagation of a large unsigned numeric constant
in the WHERE expression led to wrong result.

For example,
"WHERE a = CAST(0xFFFFFFFFFFFFFFFF AS USIGNED) AND FOO(a)",
where a is an UNSIGNED BIGINT, and FOO() accepts strings,
was transformed to "... AND FOO('-1')".

That has been fixed.

Also EXPLAIN EXTENDED printed incorrect numeric constants in
transformed WHERE expressions like above. That has been
fixed too.


mysql-test/r/bigint.result:
  Added test case for bug #45360.
mysql-test/t/bigint.test:
  Added test case for bug #45360.
sql/item.cc:
  Bug #45360: wrong results
  
  As far as Item_int_with_ref (and underlaying Item_int)
  class accepts both signed and unsigned 64bit values,
  Item_int::val_str and Item_int::print methods have been
  modified to take into account unsigned_flag.
2010-02-25 23:13:11 +04:00
Alexey Kopytov
0afa209018 Manual merge of mysql-5.1-bugteam to mysql-trunk-merge. 2010-02-22 00:33:11 +03:00
Sergey Glukhov
4b260b668d Bug#33717 INSERT...(default) fails for enum. Crashes CSV tables, loads spaces for MyISAM
Table corruption happens during table reading in ha_tina::find_current_row() func.
Field::store() method returns error(true) if stored value is 0.
The fix:
added special case for enum type which correctly processes 0 value.
Additional fix:
INSERT...(default) and INSERT...() have the same behaviour now for enum type.


mysql-test/r/csv.result:
  test result
mysql-test/r/default.result:
  result fix
mysql-test/t/csv.test:
  test case
sql/item.cc:
  Changes:
  do not print warning for 'enum' type if there is no default value.
  set default value.
storage/csv/ha_tina.cc:
  Table corruption happens during table reading in ha_tina::find_current_row() func.
  Field::store() method returns error(true) if stored value is 0.
  The fix:
  added special case for enum type which correctly processes 0 value.
2010-02-17 16:13:42 +04:00
Alexey Kopytov
0888e40fa3 Manual merge of mysql-5.1-bugteam into mysql-trunk-merge.
Conflicts:

Text conflict in .bzr-mysql/default.conf
Text conflict in mysql-test/suite/rpl/r/rpl_slow_query_log.result
Text conflict in mysql-test/suite/rpl/t/rpl_slow_query_log.test
Conflict adding files to server-tools.  Created directory.
Conflict because server-tools is not versioned, but has versioned children.  Versioned directory.
Conflict adding files to server-tools/instance-manager.  Created directory.
Conflict because server-tools/instance-manager is not versioned, but has versioned children.  Versioned directory.
Contents conflict in server-tools/instance-manager/options.cc
Text conflict in sql/mysqld.cc
2010-02-09 12:59:38 +05:00
Gleb Shchepa
994c0f8308 Bug #45640: optimizer bug produces wrong results
Grouping by a subquery in a query with a distinct aggregate
function lead to a wrong result (wrong and unordered
grouping values).

There are two related problems:

1) The query like this:

   SELECT (SELECT t1.a) aa, COUNT(DISTINCT b) c
   FROM t1 GROUP BY aa

returned wrong result, because the outer reference "t1.a"
in the subquery was substituted with the Item_ref item.

The Item_ref item obtains data from the result_field object
that refreshes once after the end of each group. This data
is not applicable to filesort since filesort() doesn't care
about groups (and doesn't update result_field objects with
copy_fields() and so on). Also that data is not applicable
to group separation algorithm: end_send_group() checks every
record with test_if_group_changed() that evaluates Item_ref
items, but it refreshes those Item_ref-s only after the end
of group, that is a vicious circle and the grouped column
values in the output are shifted.

Fix: if
       a) we grouping by a subquery and
       b) that subquery has outer references to FROM list
          of the grouping query,
     then we substitute these outer references with
     Item_direct_ref like references under aggregate
     functions: Item_direct_ref obtains data directly
     from the current record.

2) The query with a non-trivial grouping expression like:

   SELECT (SELECT t1.a) aa, COUNT(DISTINCT b) c
   FROM t1 GROUP BY aa+0

also returned wrong result, since JOIN::exec() substitutes
references to top-level aliases in SELECT list with Item_copy
caching items. Item_copy items have same refreshing policy
as Item_ref items, so the whole groping expression with
Item_copy inside returns wrong result in filesort() and
end_send_group().

Fix: include aliased items into GROUP BY item tree instead
     of Item_ref references to them.



mysql-test/r/group_by.result:
  Test case for bug #45640
mysql-test/t/group_by.test:
  Test case for bug #45640
sql/item.cc:
  Bug #45640: optimizer bug produces wrong results
  
  Item_field::fix_fields() has been modified to resolve
  aliases in GROUP BY item trees into aliased items instead
  of Item_ref items.
sql/item.h:
  Bug #45640: optimizer bug produces wrong results
  
  - Item::find_item_processor() has been introduced.
  - Item_ref::walk() has been modified to apply processors
    to itself too (not only to referenced item).
sql/mysql_priv.h:
  Bug #45640: optimizer bug produces wrong results
  
  fix_inner_refs() has been modified to accept group_list
  parameter.
sql/sql_lex.cc:
  Bug #45640: optimizer bug produces wrong results
  
  Initialization of st_select_lex::group_fix_field has
  been added.
sql/sql_lex.h:
  Bug #45640: optimizer bug produces wrong results
  
  The st_select_lex::group_fix_field field has been introduced
  to control alias resolution in Itef_fied::fix_fields.
sql/sql_select.cc:
  Bug #45640: optimizer bug produces wrong results
  
  - The fix_inner_refs function has been modified to treat
    subquery outer references like outer fields under aggregate
    functions, if they are included in GROUP BY item tree.
  
  - The find_order_in_list function has been modified to
    fix Item_field alias fields included in the GROUP BY item
    trees in a special manner.
2010-02-06 23:54:30 +04:00
Georgi Kodinov
32902dad00 Addendum to bug #46175 : use and check for the correct error values
when converting to a enumerated type.
2010-02-11 19:41:53 +02:00
Alexey Kopytov
4a1b59b7ab Manual merge of mysql-5.1-bugteam into mysql-trunk-merge. 2010-01-24 00:09:23 +03:00
Georgi Kodinov
7a7147c5b4 Bug #46175: NULL read_view and consistent read assertion
The optimizer must not continue executing the current query
if e.g. the storage engine reports an error.
This is somewhat hard to implement with Item::val_xxx()
because they do not have means to return error code.
This is why we need to check the thread's error state after
a call to one of the Item::val_xxx() methods.

Fixed store_key_item::copy_inner() to return an error state 
if an error happened during the call to Item::save_in_field() 
because it calls Item::val_xxx().
Also added similar checks to related places.
2010-01-15 16:09:20 +02:00
Alexander Nozdrin
5676713687 Manual merge from mysql-trunk.
Conflicts:
  - client/mysqltest.cc
  - mysql-test/collections/default.experimental
  - mysql-test/suite/rpl/t/disabled.def
  - sql/mysqld.cc
  - sql/opt_range.cc
  - sql/sp.cc
  - sql/sql_acl.cc
  - sql/sql_partition.cc
  - sql/sql_table.cc
2009-12-11 12:39:38 +03:00
Evgeny Potemkin
8af680218e Auto-merge. 2009-11-24 18:30:21 +03:00
Evgeny Potemkin
9f638f535e Manual merge of the fix for bug#43668. 2009-11-24 18:26:13 +03:00
Georgi Kodinov
a21cd97c35 Bug #45261 : Crash, stored procedure + decimal
Bug #48370  Absolutely wrong calculations with GROUP BY and
  decimal fields when using IF

Added the test cases in the above two bugs for regression
testing.
Added additional tests that demonstrate a incomplete fix.
Added a new factory method for Field_new_decimal to 
create a field from an (decimal returning) Item.
In the new method made sure that all the precision and 
length variables are capped in a proper way. 
This is required because Item's can have larger precision
than the decimal fields and thus need to be capped when
creating a field based on an Item type.
Fixed the wrong typecast to Item_decimal.
2009-11-20 12:10:47 +02:00
Evgeny Potemkin
bc43bff7ed Bug#43668: Wrong comparison and MIN/MAX for YEAR(2)
MySQL manual describes values of the YEAR(2) field type as follows:
values 00 - 69 mean 2000 - 2069 years and values 70 - 99 mean 1970 - 1999
years. MIN/MAX and comparison functions was comparing them as int values
thus producing wrong result.

Now the Arg_comparator class is extended with compare_year function which
performs correct comparison of the YEAR type.
The Item_sum_hybrid class now uses Item_cache and Arg_comparator objects to
correctly calculate its value.
To allow Arg_comparator to use func_name() function for Item_func and Item_sum
objects the func_name declaration is moved to the Item_result_field class.
A helper function is_owner_equal_func is added to the Arg_comparator class.
It checks whether the Arg_comparator object owner is the <=> function or not.
A helper function setup is added to the Item_sum_hybrid class. It sets up
cache item and comparator.

mysql-test/r/func_group.result:
  Added a test case for the bug#43668.
mysql-test/t/func_group.test:
  Added a test case for the bug#43668.
sql/item.cc:
  Bug#43668: Wrong comparison and MIN/MAX for YEAR(2)
  Now Item_cache_int returns the type of cached item.
sql/item.h:
  Bug#43668: Wrong comparison and MIN/MAX for YEAR(2)
  To allow Arg_comparator to use func_name() function for Item_func and Item_sum
  objects the func_name declaration is moved to the Item_result_field class.
sql/item_cmpfunc.cc:
  Bug#43668: Wrong comparison and MIN/MAX for YEAR(2)
  The Arg_comparator class is extended with compare_year function which
  performs correct comparison of the YEAR type.
sql/item_cmpfunc.h:
  Bug#43668: Wrong comparison and MIN/MAX for YEAR(2)
  The year_as_datetime variable is added to the Arg_comparator class.
  It's set to TRUE when YEAR value should be converted to the
  YYYY-00-00 00:00:00 format for correct YEAR-DATETIME comparison.
sql/item_geofunc.cc:
  Bug#43668: Wrong comparison and MIN/MAX for YEAR(2)
  Item_func_spatial_rel::val_int chenged to use Arg_comparator's string
  buffers.
sql/item_subselect.h:
  Bug#43668: Wrong comparison and MIN/MAX for YEAR(2)
  Added an implementation of the virtual func_name function.
sql/item_sum.cc:
  Bug#43668: Wrong comparison and MIN/MAX for YEAR(2)
  The Item_sum_hybrid class now uses Item_cache and Arg_comparator objects to
  correctly calculate its value.
  A helper function setup is added to the Item_sum_hybrid class. It sets up
  cache item and comparator.
sql/item_sum.h:
  Bug#43668: Wrong comparison and MIN/MAX for YEAR(2)
  The Item_sum_hybrid class now uses Item_cache and Arg_comparator objects to
  correctly calculate its value.
  Added an implementation of the virtual func_name function.
2009-11-17 17:06:46 +03:00
Alexander Nozdrin
7cd11f45be Manual merge from mysql-trunk-merge. 2009-11-06 17:20:27 +03:00
Alexander Nozdrin
1a07288310 Auto-merge from mysql-trunk-merge. 2009-11-06 12:17:01 +03:00
Davi Arnaut
1ca80ed19e Bug#48370: Absolutely wrong calculations with GROUP BY and decimal fields when using IF
Bug#45261: Crash, stored procedure + decimal

Revert fix for Bug#45261 due to unforeseen bugs.
2009-11-02 09:21:39 -02:00
Martin Hansson
740b7c4e36 Bug#47925: regression of range optimizer and date comparison in 5.1.39!
When a query was using a DATE or DATETIME value formatted
using any other separator characters beside hyphen '-', a
query with a greater-or-equal '>=' condition matching only
the greatest value in an indexed column, the result was
empty if index range scan was employed.

The range optimizer got a new feature between 5.1.38 and
5.1.39 that changes a greater-or-equal condition to a
greater-than if the value matching that in the query was not
present in the table. But the value comparison function
compared the dates as strings instead of dates.

The bug was fixed by splitting the function
get_date_from_str in two: One part that parses and does
error checking. This function is now visible outside the
module. The old get_date_from_str now calls the new
function.


mysql-test/r/range.result:
  Bug#47925: Test result
mysql-test/t/range.test:
  Bug#47925: Test case
sql/item.cc:
  Bug#47925: Fix + some edit on the comments
sql/item.h:
  Bug#47925: Changed function signature
sql/item_cmpfunc.cc:
  Bug#47925: Split function in two
sql/item_cmpfunc.h:
  Bug#47925: Declaration of new function
sql/opt_range.cc:
  Bug#47925: Added THD to function call
sql/time.cc:
  Bug#47925: Added microsecond comparison
2009-11-02 13:24:07 +01:00
Evgeny Potemkin
5594215c58 Auto-merged fix for the bug#34384. 2009-11-06 22:42:24 +03:00
Evgeny Potemkin
c81e23457a Bug#34384: Slow down on constant conversion.
When values of different types are compared they're converted to a type that
allows correct comparison. This conversion is done for each comparison and
takes some time. When a constant is being compared it's possible to cache the
value after conversion to speedup comparison. In some cases (large dataset,
complex WHERE condition with many type conversions) query might be executed
7% faster.

A test case isn't provided because all changes are internal and isn't visible
outside.

The behavior of the Item_cache is changed to cache values on the first request
of cached value rather than at the moment of storing item to be cached.
A flag named value_cached is added to the Item_cache class. It's set to TRUE
when cache holds the value of the last stored item.
Function named cache_value() is added to the Item_cache class and derived classes.
This function actually caches the value of the saved item.
Item_cache_xxx::store functions now only store item to be cached and set
value_cached flag to FALSE.
Item_cache_xxx::val_xxx functions are changed to call cache_value function
prior to returning cached value if value_cached is FALSE.
The Arg_comparator::set_cmp_func function now calls cache_converted_constant
to cache constants if they need a type conversion.
The Item_cache::get_cache function is overloaded to allow setting of the
cache type.
The cache_converted_constant function is added to the Arg_comparator class.
It checks whether a value can and should be cached and if so caches it.

sql/item.cc:
  Bug#34384: Slow down on constant conversion.
  Function named cache_value() is added to the Item_cache class and derived classes.
  This function actually caches the value of the saved item.
  Item_cache_xxx::store functions now only store item to be cached and set
  value_cached flag to FALSE.
  Item_cache_xxx::val_xxx functions are changed to call cache_value function
  prior to returning cached value if value_cached is FALSE.
  The Item_cache::get_cache function is overloaded to allow setting of the
  cache type.
sql/item.h:
  Bug#34384: Slow down on constant conversion.
  A flag named value_cached is added to the Item_cache class. It's set to TRUE
  when we need to start caching values when the store method is called.
  Function named cache_value() is added to the Item_cache class and derived classes.
sql/item_cmpfunc.cc:
  Bug#34384: Slow down on constant conversion.
  A helper function cache_converted_constant is added to the Arg_comparator class.
  It checks whether a given item can and should be cached and caches it if so.
  The Arg_comparator::set_cmp_func function now calls cache_converted_constant
  to cache constants if they need a type conversion.
sql/item_cmpfunc.h:
  Bug#34384: Slow down on constant conversion.
  The cache_converted_constant function is added to the Arg_comparator class.
  It checks whether a value can and should be cached and if so caches it.
sql/item_subselect.cc:
  Bug#34384: Slow down on constant conversion.
  Force immediate caching of subselect result.
sql/item_xmlfunc.cc:
  Bug#34384: Slow down on constant conversion.
sql/sp_rcontext.cc:
  Bug#34384: Slow down on constant conversion.
  Force immediate caching of values of an SP CASE function.
2009-11-06 22:34:25 +03:00
Alexander Nozdrin
2dc132b209 Merge from mysql-next-mr. 2009-10-23 15:22:21 +04:00
Konstantin Osipov
8ec23470f1 Backport of revno 2630.28.10, 2630.28.31, 2630.28.26, 2630.33.1,
2630.39.1, 2630.28.29, 2630.34.3, 2630.34.2, 2630.34.1, 2630.29.29,
2630.29.28, 2630.31.1, 2630.28.13, 2630.28.10, 2617.23.14 and
some other minor revisions.

This patch implements: 

WL#4264 "Backup: Stabilize Service Interface" -- all the
server prerequisites except si_objects.{h,cc} themselves (they can
be just copied over, when needed).

WL#4435: Support OUT-parameters in prepared statements.

(and all issues in the initial patches for these two
tasks, that were discovered in pushbuild and during testing).

Bug#39519: mysql_stmt_close() should flush all data
associated with the statement.

After execution of a prepared statement, send OUT parameters of the invoked
stored procedure, if any, to the client.

When using the binary protocol, send the parameters in an additional result
set over the wire.  When using the text protocol, assign out parameters to
the user variables from the CALL(@var1, @var2, ...) specification.

The following refactoring has been made:
  - Protocol::send_fields() was renamed to Protocol::send_result_set_metadata();
  - A new Protocol::send_result_set_row() was introduced to incapsulate
    common functionality for sending row data.
  - Signature of Protocol::prepare_for_send() was changed: this operation
    does not need a list of items, the number of items is fully sufficient.

The following backward incompatible changes have been made:
  - CLIENT_MULTI_RESULTS is now enabled by default in the client;
  - CLIENT_PS_MULTI_RESUTLS is now enabled by default in the client.

include/mysql.h:
  Add a new flag to MYSQL_METHODS::flush_use_result
  function pointer. This flag determines if all results
  should be flushed or only the first one:
      
  - if flush_all_results is TRUE, then cli_flush_use_result()
    will read/flush all pending results. I.e. it will read
    all packets while server status attribute indicates that
    there are more results. This is a new semantic, required
    to fix the bug.
              
  - if flush_all_results is FALSE, the old sematic
    is preserved -- i.e. cli_flush_use_result() reads data
    until first EOF-packet.
include/mysql.h.pp:
  Update the ABI with new calls (compatible changes).
include/mysql_com.h:
  Add CLIENT_PS_OUT_PARAMS -- a client capability indicating that the client supportsю
libmysql/libmysql.c:
  Add mysql_stmt_next_result() -- analogue of mysql_next_result() for binary protocol.
  Fix a minor bug in alloc_fields() -- not all members were copied over,
  and some only shallow-copied (catalog).
  Flush all results in mysql_stmt_close() (Bug#39519).
libmysqld/lib_sql.cc:
  Rename send_fields() -> send_result_set_metadata().
  Refactoring: change prepare_for_send() so that it accepts only 
  what it really needs -- a number of elements in the list.
mysql-test/r/ps.result:
  Update results: WL#4435.
mysql-test/t/ps.test:
  WL#4435: A test case for an SQL-part of the problem.
sql-common/client.c:
  Bug#39519.
  Implement new functionality in cli_flush_use_result():
  if flush_all_delete is TRUE, then it should read/flush
  all pending results.
sql/Makefile.am:
  Add a new header sql_prepare.h to the list
  of build headers.
sql/events.cc:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
sql/handler.cc:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
sql/mysql_priv.h:
  Move sql_prepare.cc-specific declarations to a new
  header - sql_prepare.h.
sql/procedure.h:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
sql/protocol.cc:
  Move the logic responsible for sending of one result
  set row to the Protocol class. Define a template
  for end-of-statement action. 
  Refactoring: change prepare_for_send() so that it accepts 
  only what it really needs -- a number of elements in the list.
  Rename send_fields() to send_result_set_metadata().
sql/protocol.h:
  Update with new declarations (WL#4435).
  Rename send_fields() -> send_result_set_metadata().
  prepare_for_send() only needs the number of columns to send,
  and doesn't use the item list - update signature to require
  only what's needed.
  Add a new protocol type -- Protocol_local.
sql/repl_failsafe.cc:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
sql/slave.cc:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
sql/sql_acl.cc:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
sql/sql_base.cc:
  Include sql_prepare.h (for Reprepare_observer).
sql/sql_cache.cc:
  Extend the query cache flags block to be able
  to store a numeric id for the result format,
  not just a flag binary/non-binary.
sql/sql_class.cc:
  Update to use the rename of Protocol::send_fields()
  to Protocol::send_result_set_metadata().
  Use Protocol::send_one_result_set_row().
sql/sql_class.h:
  Move the declaration of Reprepare_observer to the 
  new header - sql_prepare.h.
  Update to the new signature of class Protocol::send_fields().
sql/sql_connect.cc:
  Use a protocol template method instead of
  raw NET layer API at the end of a statement.
sql/sql_cursor.cc:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
sql/sql_error.cc:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
sql/sql_handler.cc:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
  Use new method Protocol::send_one_result_set_row().
sql/sql_help.cc:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
sql/sql_lex.cc:
  Initialize multi_statements variable.
  Add a handy constant for empty lex
  string.
sql/sql_lex.h:
  Add a separate member for a standalone
  parsing option - multi-statements support.
sql/sql_list.cc:
  sql_list.h is a standalone header now, 
  no need to include mysql_priv.h.
sql/sql_list.h:
  Make sql_list.h a stand-alone header.
sql/sql_parse.cc:
  Include sql_prepare.h for prepared
  statements- related declarations.
  Use a new Protocol template method to end
  each statement (send OK, EOF or ERROR to
  the client).
sql/sql_prepare.cc:
  Implement Execute Direct API (WL#4264), 
  currently unused. It will be used by the service
  interface (Backup).
  Use a new header - sql_prepare.h.
  Add support for OUT parameters in the 
  binary and text protocol (prepared statements 
  only).
sql/sql_prepare.h:
  Add a new header to contain (for now)
  all prepared statement- external
  related declarations.
sql/sql_profile.cc:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
sql/sql_repl.cc:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
sql/sql_select.cc:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
sql/sql_show.cc:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
sql/sql_string.h:
  Add a way to convert a String to LEX_STRING.
sql/sql_table.cc:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
sql/sql_update.cc:
  Remove an extraneous my_error(). The error
  is already reported in update_non_unique_table_error().
sql/sql_yacc.yy:
  Support for multi-statements is an independent
  property of parsing, not derived from 
  the protocol type.
tests/mysql_client_test.c:
  Add tests for WL#4435 (binary protocol).
2009-10-22 00:02:06 +04:00
Alexander Barkov
dcb8bb23c2 Merging mysql-next-mr-merge to mysql-next-mr. 2009-10-21 15:48:22 +05:00
Sergey Glukhov
d8c3f2263f WL#751 Error message construction, backport 2009-10-15 17:23:43 +05:00
Alexander Nozdrin
c30d924dd5 Manual merge from mysql-trunk-merge. 2009-10-14 12:25:39 +04:00
Ramil Kalimullin
662d836744 Fix for bug#47963: Wrong results when index is used
Problem: using null microsecond part (e.g. "YYYY-MM-DD HH:MM:SS.0000") 
in a WHERE condition may lead to wrong results due to improper
DATETIMEs comparison in some cases.

Fix: as we compare DATETIMEs as strings we must trim trailing 0's
in such cases.


mysql-test/r/innodb_mysql.result:
  Fix for bug#47963: Wrong results when index is used
    - test result.
mysql-test/t/innodb_mysql.test:
  Fix for bug#47963: Wrong results when index is used
    - test case.
sql/item.cc:
  Fix for bug#47963: Wrong results when index is used
    - comparing DATETIMEs trim trailing 0's in the 
  microsecond part.
2009-10-13 09:43:27 +05:00
Sergey Glukhov
5f8bb5c507 Bug#47150 Assertion in Field_long::val_int() on MERGE + TRIGGER + multi-table UPDATE
The bug is not related to MERGE table or TRIGGER. More correct description
would be 'assertion on multi-table UPDATE + NATURAL JOIN + MERGEABLE VIEW'.
On PREPARE stage(see test case) we call mark_common_columns() func which
creates ON condition for NATURAL JOIN and sets appropriate
table read_set bitmaps for fields which are used in ON condition.
On EXECUTE stage mark_common_columns() is not called, we set
necessary read_set bitmaps in setup_conds(). But 'B.f1' field
is already processed and related item alredy fixed before
setup_conds() as updated field and setup_conds can not set
read_set bitmap because of that.
The fix is to set read_set bitmap for appropriate table field even
if Item_direct_view_ref item which represents a refernce to this field
is fixed.



mysql-test/r/join.result:
  test result
mysql-test/t/join.test:
  test case
sql/item.cc:
  The bug is not related to MERGE table or TRIGGER. More correct description
  would be 'assertion on multi-table UPDATE + NATURAL JOIN + MERGEABLE VIEW'.
  On PREPARE stage(see test case) we call mark_common_columns() func which
  creates ON condition for NATURAL JOIN and sets appropriate
  table read_set bitmaps for fields which are used in ON condition.
  On EXECUTE stage mark_common_columns() is not called, we set
  necessary read_set bitmaps in setup_conds(). But 'B.f1' field
  is already processed and related item alredy fixed before
  setup_conds() as updated field and setup_conds can not set
  read_set bitmap because of that.
  The fix is to set read_set bitmap for appropriate table field even
  if Item_direct_view_ref item which represents a refernce to this field
  is fixed.
2009-09-29 07:23:38 +05:00
Marc Alff
071634bb35 Merge mysql-next-mr --> mysql-trunk-signal 2009-09-17 03:20:11 -06:00
Marc Alff
63e56390a3 WL#2110 (SIGNAL)
WL#2265 (RESIGNAL)

Manual merge of SIGNAL and RESIGNAL to mysql-trunk-signal,
plus required dependencies.
2009-09-10 03:18:29 -06:00
Staale Smedseng
5be4c38226 Merge from 5.0 for 43414 2009-08-28 18:21:54 +02:00
Staale Smedseng
1ba25ae47c Bug #43414 Parenthesis (and other) warnings compiling MySQL
with gcc 4.3.2
      
This patch fixes a number of GCC warnings about variables used
before initialized. A new macro UNINIT_VAR() is introduced for
use in the variable declaration, and LINT_INIT() usage will be
gradually deprecated. (A workaround is used for g++, pending a
patch for a g++ bug.)
      
GCC warnings for unused results (attribute warn_unused_result)
for a number of system calls (present at least in later
Ubuntus, where the usual void cast trick doesn't work) are
also fixed.


client/mysqlmanager-pwgen.c:
  A fix for warn_unused_result, adding fallback to use of
  srand()/rand() if /dev/random cannot be used. Also actually
  adds calls to rand() in the second branch so that it actually
  creates a random password.
2009-08-28 17:51:31 +02:00
Davi Arnaut
169f7da04c Fix for a few assorted compiler warnings.
client/mysql.cc:
  Remove leading whitespace.
  Remove extra text after #else directive.
client/mysqldump.c:
  Function does not take a parameter.
mysys/array.c:
  buffer is a uchar pointer.
sql/item.cc:
  Assert if it should not happen.
storage/myisam/mi_check.c:
  Cast to expected type. This is probably a bug, but it is
  casted in a similar way in another part of the code.
storage/ndb/include/mgmapi/ndb_logevent.h:
  Apply fix from cluster team.
tests/mysql_client_test.c:
  Remove extraneous slash.
2009-08-28 12:06:59 -03:00
Mattias Jonsson
0a76397171 Manual merge between bug#46362 and bug#20577.
sql/opt_range.cc:
  Removed duplicate code (if statement must have been duplicated during earlier merge).
sql/sql_partition.cc:
  After mergeing bug#46362 and bug#20577, the NULL partition was also searched
  when col = const, fixed by checking if = or range.
2009-08-28 12:55:59 +02:00
Mattias Jonsson
4655118bea Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
There were a problem since pruning uses the field
for comparison (while evaluate_join_record uses longlong),
resulting in pruning failures when comparing DATE to DATETIME.

Fix was to always comparing DATE vs DATETIME as DATETIME,
by adding ' 00:00:00' to the DATE string.

And adding optimization for comparing with 23:59:59, so that
DATETIME_col > '2001-02-03 23:59:59' ->
TO_DAYS(DATETIME_col) > TO_DAYS('2001-02-03 23:59:59') instead
of '>='.

mysql-test/r/partition_pruning.result:
  Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
  
  Updated result-file
mysql-test/t/partition_pruning.test:
  Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
  
  Added testcases.
sql-common/my_time.c:
  Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
  
  removed duplicate assignment.
sql/item.cc:
  Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
  
  Changed field_is_equal_to_item into field_cmp_to_item, to
  better handling DATE vs DATETIME comparision.
sql/item.h:
  Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
  
  Updated comment
sql/item_timefunc.cc:
  Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
  
  Added optimization (pruning) of DATETIME where time-part is
  23:59:59
sql/opt_range.cc:
  Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
  
  Using the new stored_field_cmp_to_item for better pruning.
2009-08-26 12:51:23 +02:00
Davi Arnaut
fc39459504 Bug#45261: Crash, stored procedure + decimal
The problem was that creating a DECIMAL column from a decimal
value could lead to a failed assertion as decimal values can
have a higher precision than those attached to a table. The
assert could be triggered by creating a table from a decimal
with a large (> 30) scale. Also, there was a problem in
calculating the number of digits in the integral and fractional
parts if both exceeded the maximum number of digits permitted
by the new decimal type.

The solution is to ensure that truncation procedure is executed
when deducing a DECIMAL column from a decimal value of higher
precision. If the integer part is equal to or bigger than the
maximum precision for the DECIMAL type (65), the integer part
is truncated to fit and the fractional becomes zero. Otherwise,
the fractional part is truncated to fit into the space left
after the integer part is copied.

This patch borrows code and ideas from Martin Hansson's patch.

mysql-test/r/type_newdecimal.result:
  Add test case result for Bug#45261. Also, update test case to
  reflect that an additive operation increases the precision of
  the resulting type by 1.
mysql-test/t/type_newdecimal.test:
  Add test case for Bug#45261
sql/field.cc:
  Added DBUG_ASSERT to ensure object's invariant is maintained.
  Implement method to create a field to hold a decimal value
  from an item.
sql/field.h:
  Explain member variable. Add method to create a new decimal field.
sql/item.cc:
  The precision should only be capped when storing the value
  on a table. Also, this makes it impossible to calculate the
  integer part if Item::decimals (the scale) is larger than the
  precision.
sql/item.h:
  Simplify calculation of integer part.
sql/item_cmpfunc.cc:
  Do not limit the precision. It will be capped later.
sql/item_func.cc:
  Use new method for allocating a new decimal field.
  Add a specialized method for retrieving the precision
  of a user variable item.
sql/item_func.h:
  Add method to return the precision of a user variable.
sql/item_sum.cc:
  Use new method for allocating a new decimal field.
sql/my_decimal.h:
  The integer part could be improperly calculated for a decimal
  with 31 digits in the fractional part.
sql/sql_select.cc:
  Use new method which truncates the integer or decimal parts
  as needed.
2009-08-24 16:47:08 -03:00
Evgeny Potemkin
bc016c54ca Merged fix for the bug#46051. 2009-07-19 16:49:40 +04:00
Evgeny Potemkin
5032380084 Bug#46051: Incorrectly market field caused wrong result.
When during the optimization an item is moved to the upper select
the item's context left unchanged. This caused wrong result in the 
PS/SP mode.
The Item_ident::remove_dependence_processor now sets the context
of the select to which the item is moved to.

mysql-test/r/subselect.result:
  The test case for the bug#46051 is adjusted.
mysql-test/t/subselect.test:
  The test case for the bug#46051 is adjusted.
sql/item.cc:
  Bug#46051: Incorrectly market field caused wrong result.
  The Item_ident::remove_dependence_processor now sets the context
  of the select to which the item is moved to.
2009-07-18 18:09:56 +04:00
Alexey Kopytov
cfebaf442a Automerge. 2009-07-03 14:43:54 +04:00
Alexey Kopytov
2d4df13ef2 Manual merge. 2009-07-03 14:36:04 +04:00
Alexey Kopytov
096c12b2c4 Bug #45262: Bad effects with CREATE TABLE and DECIMAL
Using DECIMAL constants with more than 65 digits in CREATE 
TABLE ... SELECT led to bogus errors in release builds or 
assertion failures in debug builds. 
 
The problem was in inconsistency in how DECIMAL constants and 
fields are handled internally. We allow arbitrarily long 
DECIMAL constants, whereas DECIMAL(M,D) columns are limited to 
M<=65 and D<=30. my_decimal_precision_to_length() was used in 
both Item and Field code and truncated precision to 
DECIMAL_MAX_PRECISION when calculating value length without 
adjusting precision and decimals. As a result, a DECIMAL 
constant with more than 65 digits ended up having length less 
than precision or decimals which led to assertion failures. 
 
Fixed by modifying my_decimal_precision_to_length() so that 
precision is truncated to DECIMAL_MAX_PRECISION only for Field 
object which is indicated by the new 'truncate' parameter. 
 
Another inconsistency fixed by this patch is how DECIMAL 
constants and expressions are handled for CREATE ... SELECT. 
create_tmp_field_from_item() (which is used for constants) was 
changed as a part of the bugfix for bug #24907 to handle long 
DECIMAL constants gracefully. Item_func::tmp_table_field() 
(which is used for expressions) on the other hand was still 
using a simplistic approach when creating a Field_new_decimal 
from a DECIMAL expression. 

mysql-test/r/type_newdecimal.result:
  Added a test case for bug #45262.
mysql-test/t/type_newdecimal.test:
  Added a test case for bug #45262.
sql/item.cc:
  Use the new 'truncate' parameter in 
  my_decimal_precision_to_length().
sql/item_cmpfunc.cc:
  Use the new 'truncate' parameter in 
  my_decimal_precision_to_length().
sql/item_func.cc:
  1. Use the new 'truncate' parameter in 
  my_decimal_precision_to_length().
  
  2. Do not truncate decimal precision to DECIMAL_MAX_PRECISION
  for additive expressions involving long DECIMAL constants.
  
  3. Fixed an incosistency in how DECIMAL constants and 
  expressions are handled for CREATE ... SELECT.
sql/item_func.h:
  Use the new 'truncate' parameter in 
  my_decimal_precision_to_length().
sql/item_sum.cc:
  Use the new 'truncate' parameter in 
  my_decimal_precision_to_length().
sql/my_decimal.h:
  Do not truncate precision to DECIMAL_MAX_PRECISION
  when calculating length in 
  my_decimal_precision_to_length() if 'truncate' parameter
  is FALSE.
sql/sql_select.cc:
  1. Use the new 'truncate' parameter in 
  my_decimal_precision_to_length().
  
  2. Use a more correct logic when adjusting value's length.
2009-07-03 11:41:19 +04:00
Georgi Kodinov
ae8950f1e8 Bug #45807: crash accessing partitioned table and sql_mode
contains ONLY_FULL_GROUP_BY

The partitioning code needs to issue a Item::fix_fields()
on the partitioning expression in order to prepare 
it for being evaluated.
It does this by creating a special table and a table list 
for the scope of the partitioning expression.
But when checking ONLY_FULL_GROUP_BY the 
Item_field::fix_fields() was relying that there always be
cached_table set and was trying to use it to get the 
select_lex of the SELECT the field's table is in.
But the cached_table was not set by the partitioning code
that creates the artificial TABLE_LIST used to resolve the
partitioning expression and this resulted in a crash.
 
Fixed by rectifying the following errors :
1. Item_field::fix_fields() : the code that check for 
ONLY_FULL_GROUP_BY relies on having tables with 
cacheable_table set. This is mostly true, the only 
two exceptions being the partitioning context table
and the trigger context table.
Fixed by taking the current parsing context if no pointer
to the TABLE_LIST instance is present in the cached_table.

2. fix_fields_part_func() : 

2a. The code that adds the table being created to the 
scope for the partitioning expression is mostly a copy 
of the add_table_to_list and friends with one exception :
it was not marking the table as cacheable (something that
normal add_table_to_list is doing). This caused the 
problem in the check for ONLY_FULL_GROUP_BY in 
Item_field::fix_fields() to appear.
Fixed by setting the correct members to make the table
cacheable.
The ideal structural fix for this is to use a unified 
interface for adding a table to a table list 
(add_table_to_list?) : noted in a TODO comment

2b. The Item::fix_fields() was called with a NULL destination
pointer. This causes uninitalized memory reads in the 
overloaded ::fix_fields() function (namely 
Item_field::fix_fields()) as it expects a non-zero pointer 
there. Fixed by passing the source pointer similarly to how 
it's done in JOIN::prepare().

mysql-test/r/partition.result:
  Bug #45807: test case
mysql-test/t/partition.test:
  Bug #45807: test case
sql/item.cc:
  Bug #45807: fix the ONLY_FULL_GROUP_BY check code to 
  handle correctly non-cacheable tables.
sql/sql_partition.cc:
  Bug #45807: fix the Item::fix_fields() context
  initializatio for the partitioning expression in 
  CREATE TABLE.
2009-07-02 17:42:00 +03:00
Sergey Glukhov
bebc987595 Bug#45485 replication different between master/slaver using procedure with gbk
In Item_param::set_from_user_var
value.cs_info.character_set_client is set
to 'fromcs' value. It's wrong, it should be set to
thd->variables.character_set_client.



mysql-test/r/ctype_gbk_binlog.result:
  test result
mysql-test/t/ctype_gbk_binlog.test:
  test case
sql/item.cc:
  In Item_param::set_from_user_var
  value.cs_info.character_set_client is set
  to 'fromcs' value. It's wrong, it should be set to
  thd->variables.character_set_client.
2009-06-25 11:22:39 +05:00
Staale Smedseng
2380d465f0 Merge from 5.0-bugteam 2009-06-17 16:56:44 +02:00
Staale Smedseng
3b0e6e4109 Bug #43414 Parenthesis (and other) warnings compiling MySQL
with gcc 4.3.2
      
Compiling MySQL with gcc 4.3.2 and later produces a number of 
warnings, many of which are new with the recent compiler
versions.
                  
This bug will be resolved in more than one patch to limit the
size of changesets. This is the second patch, fixing more
of the warnings.
2009-06-17 15:54:01 +02:00
Staale Smedseng
a103509788 Bug #43414 Parenthesis (and other) warnings compiling MySQL
with gcc 4.3.2

Compiling MySQL with gcc 4.3.2 and later produces a number of 
warnings, many of which are new with the recent compiler
versions.
            
This bug will be resolved in more than one patch to limit the
size of changesets. This is the second patch, fixing more
of the warnings.
2009-06-10 16:04:07 +02:00
Staale Smedseng
a073ee45c2 Bug #43414 Parenthesis (and other) warnings compiling MySQL
with gcc 4.3.2
      
Compiling MySQL with gcc 4.3.2 and later produces a number of 
warnings, many of which are new with the recent compiler
versions.
      
This bug will be resolved in more than one patch to limit the
size of changesets. This is the first patch, fixing a number 
of the warnings, predominantly "suggest using parentheses 
around && in ||", and empty for and while bodies.
2009-06-09 18:11:21 +02:00
Georgi Kodinov
8c18db4c8e merged 36995 to 5.1-bugteam 2009-06-04 13:26:18 +03:00
Georgi Kodinov
a037071a75 Bug #36995: valgrind error in remove_const during subquery executions
When copying the Item class one must copy its attributes as well.

mysql-test/r/innodb_mysql.result:
  Bug #36995: test case
mysql-test/t/innodb_mysql.test:
  Bug #36995: test case
sql/item.cc:
  Bug #36995: copy attributes in the copy constructor
2009-06-04 12:52:40 +03:00
Georgi Kodinov
7348140465 Bug #44399 : crash with statement using TEXT columns, aggregates, GROUP BY, and
HAVING
            
When calculating GROUP BY the server caches some expressions. It does
that by allocating a string slot (Item_copy_string) and assigning the 
value of the expression to it. This effectively means that the result
type of the expression can be changed from whatever it was to a string.
As this substitution takes place after the compile-time result type 
calculation for IN but before the run-time type calculations, 
it causes the type calculations in the IN function done at run time 
to get unexpected results different from what was prepared at compile time.
                  
In the CASE ... WHEN ... THEN ... statement there was a similar problem
and it was solved by artificially adding a STRING argument to the set of 
types of the IN/CASE arguments at compile time, so if any of the 
arguments of the CASE function changes its type to a string it will 
still be covered by the information prepared at compile time.

mysql-test/include/mix1.inc:
  Bug #44399: extended the test to cover the different types
mysql-test/r/func_in.result:
  Bug #44399: test case
mysql-test/r/innodb_mysql.result:
  Bug #44399: extended the test to cover the different types
mysql-test/t/func_in.test:
  Bug #44399: test case
sql/item.cc:
  Bug #44399: Implement typed caching for GROUP BY
sql/item.h:
  Bug #44399: Implement typed caching for GROUP BY
sql/item_cmpfunc.cc:
  Bug #44399: remove the special case
sql/sql_select.cc:
  Bug #44399: Implement typed caching for GROUP BY
2009-05-25 11:00:40 +03:00
Gleb Shchepa
06142cd545 Bug #42778: delete order by null global variable causes
assertion .\filesort.cc, line 797

A query with the "ORDER BY @@some_system_variable" clause,
where @@some_system_variable is NULL, causes assertion
failure in the filesort procedures.

The reason of the failure is in the value of
Item_func_get_system_var::maybe_null: it was unconditionally
set to false even if the value of a variable was NULL.


mysql-test/r/variables.result:
  Added test case for bug #42778.
mysql-test/suite/sys_vars/r/innodb_data_home_dir_basic.result:
  Updated test case for bug #42778:
  system variables were NOT NULL, now they are nullable.
mysql-test/suite/sys_vars/r/innodb_flush_method_basic.result:
  Updated test case for bug #42778:
  system variables were NOT NULL, now they are nullable.
mysql-test/suite/sys_vars/r/rpl_init_slave_func.result:
  Updated test case for bug #42778:
  system variables were NOT NULL, now they are nullable.
mysql-test/suite/sys_vars/r/ssl_capath_basic.result:
  Updated test case for bug #42778:
  system variables were NOT NULL, now they are nullable.
mysql-test/suite/sys_vars/r/ssl_cipher_basic.result:
  Updated test case for bug #42778:
  system variables were NOT NULL, now they are nullable.
mysql-test/suite/sys_vars/t/innodb_data_home_dir_basic.test:
  Updated test case for bug #42778:
  system variables were NOT NULL, now they are nullable.
mysql-test/suite/sys_vars/t/innodb_flush_method_basic.test:
  Updated test case for bug #42778:
  system variables were NOT NULL, now they are nullable.
mysql-test/suite/sys_vars/t/ssl_capath_basic.test:
  Updated test case for bug #42778:
  system variables were NOT NULL, now they are nullable.
mysql-test/suite/sys_vars/t/ssl_cipher_basic.test:
  Updated test case for bug #42778:
  system variables were NOT NULL, now they are nullable.
mysql-test/t/variables.test:
  Added test case for bug #42778.
sql/item.cc:
  Bug #42778: delete order by null global variable causes
              assertion .\filesort.cc, line 797
  
  The longlong_from_string_with_check function has been modified
  to skip unwanted warnings: now it uses the THD::no_errors
  flag to suppress warnings.
  The Item_func_get_system_var::update_null_value method
  sets the no_error flag.
sql/item_func.cc:
  Bug #42778: delete order by null global variable causes
              assertion .\filesort.cc, line 797
  
  1. The Item_func_get_system_var::fix_length_and_dec method
     has been modified to make system variables truly nullable.
  
  2. The Item_func_get_system_var::update_null_value method
     method has been overloaded with a simple wrapper (like
     Item_field::update_null_value) to suppress unwanted warnings
     from Item_func_get_system_var::val_int() calls on non-numeric
     variable values: the Item_func_get_system_var::update_null_value
     method sets and restores THD::no_errors flag for a nested
     call of the longlong_from_string_with_check function.
sql/item_func.h:
  Bug #42778: delete order by null global variable causes
              assertion .\filesort.cc, line 797
  
  The Item_func_get_system_var::update_null_value method
  method has been overloaded.
2009-05-22 01:22:46 +05:00