1
0
mirror of https://github.com/MariaDB/server.git synced 2025-08-08 11:22:35 +03:00
Commit Graph

2571 Commits

Author SHA1 Message Date
Ramil Kalimullin
c888a4a239 Manual merge. 2009-12-10 10:31:52 +04:00
Ramil Kalimullin
7171282fb7 Manual merge. 2009-12-10 10:31:52 +04:00
Gleb Shchepa
3246383301 Bug #49480: WHERE using YEAR columns returns unexpected results
A few problems were found in the fix for bug 43668:
1) Comparison of the YEAR column with NULL always returned TRUE;
2) Comparison of the YEAR column with constants always returned
   unpredictable result;
3) Unnecessary conversion warnings when comparing a non-integer
   constant with a NULL value in the YEAR column;

The problems described above have been resolved with an
exception: zero (i.e. invalid) YEAR column value comparison
with 00 or 2000 still fail (it is not a regression and it was
not a regression), so MIN/MAX on YEAR column containing zero
value still fail.


mysql-test/r/type_year.result:
  Test case for bug #49480.
mysql-test/t/type_year.test:
  Test case for bug #49480.
sql/item_cmpfunc.cc:
  - The get_year_value() function has been modified to make its
    return value compatible with the get_datetime_value() return
    value (i.e. to convert numeric values into the YYYY0000000000
    (YYYY-00-00 00:00:00) form.
  
  - The Arg_comparator::set_cmp_func method has been modified to
    use the get_year_value function if get_datetime_value() is not
    applicable.
    From now only 2 cases have a special processing there:
    * both comparing items have MYSQL_TYPE_YEAR field type
            or
    * one item have is MYSQL_TYPE_YEAR and other one is
      is_datetime()-compliant.
  
  - New helper function try_year_cmp_func() has been
    added for the better code readability to call from
    Arg_comparator::set_cmp_func().
  
  - The Arg_comparator::compare_year method has been removed
    since get_year_value() is compatible with the old
    Arg_comparator::compare_datetime method that doesn't have
    problems #1-#3 (see whole patch entry commentary).
sql/item_cmpfunc.h:
  - New helper function try_year_cmp_func() has been
    added for the better code readability to call from
    Arg_comparator::set_cmp_func().
  
  - Unnecessary Arg_comparator::year_as_datetime and
    Arg_comparator::compare_year() declarations have been
    removed.
2009-12-10 10:05:44 +04:00
Gleb Shchepa
3461cdc1a1 Bug #49480: WHERE using YEAR columns returns unexpected results
A few problems were found in the fix for bug 43668:
1) Comparison of the YEAR column with NULL always returned TRUE;
2) Comparison of the YEAR column with constants always returned
   unpredictable result;
3) Unnecessary conversion warnings when comparing a non-integer
   constant with a NULL value in the YEAR column;

The problems described above have been resolved with an
exception: zero (i.e. invalid) YEAR column value comparison
with 00 or 2000 still fail (it is not a regression and it was
not a regression), so MIN/MAX on YEAR column containing zero
value still fail.
2009-12-10 10:05:44 +04:00
Evgeny Potemkin
1285ecd468 Bug#49489: Uninitialized cache led to a wrong result.
Arg_comparator uses Item_cache objects to store constants being compared when
they're need a type conversion. Because this cache wasn't initialized properly
Arg_comparator might produce wrong comparison result.

The Arg_comparator::cache_converted_constant function now initializes cache
prior to usage.

mysql-test/r/select.result:
  Added a test case for he bug#49489.
mysql-test/t/select.test:
  Added a test case for he bug#49489.
sql/item_cmpfunc.cc:
  Bug#49489: Uninitialized cache led to a wrong result.
  The Arg_comparator::cache_converted_constant function now initializes cache
  prior to usage.
2009-12-09 18:43:45 +03:00
Evgeny Potemkin
69fa790fbd Bug#49489: Uninitialized cache led to a wrong result.
Arg_comparator uses Item_cache objects to store constants being compared when
they're need a type conversion. Because this cache wasn't initialized properly
Arg_comparator might produce wrong comparison result.

The Arg_comparator::cache_converted_constant function now initializes cache
prior to usage.
2009-12-09 18:43:45 +03:00
Ramil Kalimullin
f5b51bc1e2 Fix for bug#49199: Optimizer handles incorrectly:
field='const1' AND field='const2' in some cases

Building multiple equality predicates containing
a constant which is compared as a datetime (with a field)
we should take this fact into account and compare the 
constant with another possible constatns as datetimes 
as well.

E.g. for the
SELECT ... WHERE a='2001-01-01' AND a='2001-01-01 00:00:00'
we should compare '2001-01-01' with '2001-01-01 00:00:00' as
datetimes but not as strings.


mysql-test/r/select.result:
  Fix for bug#49199: Optimizer handles incorrectly: 
  field='const1' AND field='const2' in some cases
    - test result.
mysql-test/t/select.test:
  Fix for bug#49199: Optimizer handles incorrectly: 
  field='const1' AND field='const2' in some cases
    - test case.
sql/item_cmpfunc.cc:
  Fix for bug#49199: Optimizer handles incorrectly: 
  field='const1' AND field='const2' in some cases
    - adding a constant to Item_equal compare it as
  a datetime value with stored one if there's a 
  date[time] field in a equality predicate.
sql/item_cmpfunc.h:
  Fix for bug#49199: Optimizer handles incorrectly: 
  field='const1' AND field='const2' in some cases
    - adding a constant to Item_equal compare it as
  a datetime value with stored one if there's a 
  date[time] field in a equality predicate.
sql/sql_select.cc:
  Fix for bug#49199: Optimizer handles incorrectly: 
  field='const1' AND field='const2' in some cases
    - adding a constant to Item_equal compare it as
  a datetime value with stored one if there's a 
  date[time] field in a equality predicate.
2009-12-04 21:58:40 +04:00
Ramil Kalimullin
7888c98327 Fix for bug#49199: Optimizer handles incorrectly:
field='const1' AND field='const2' in some cases

Building multiple equality predicates containing
a constant which is compared as a datetime (with a field)
we should take this fact into account and compare the 
constant with another possible constatns as datetimes 
as well.

E.g. for the
SELECT ... WHERE a='2001-01-01' AND a='2001-01-01 00:00:00'
we should compare '2001-01-01' with '2001-01-01 00:00:00' as
datetimes but not as strings.
2009-12-04 21:58:40 +04:00
Evgeny Potemkin
1eda9dc777 Auto-merged. 2009-12-02 16:49:21 +03:00
Evgeny Potemkin
e4344ffa41 Auto-merged. 2009-12-02 16:49:21 +03:00
Evgeny Potemkin
9e5d1bb664 Auto-merged fix for the bug#34384. 2009-12-01 22:41:39 +03:00
Evgeny Potemkin
17a4c595bc Auto-merged fix for the bug#34384. 2009-12-01 22:41:39 +03:00
Evgeny Potemkin
7853f553be Bug#48508: Crash on prepared statement re-execution.
Actually there is two different bugs.
The first one caused crash on queries with WHERE condition over views
containing WHERE condition. A wrong check for prepared statement phase led
to items for view fields being allocated in the execution memory and freed
at the end of execution. Thus the optimized WHERE condition refers to
unallocated memory on the second execution and server crashed.
The second one caused by the Item_cond::compile function not saving changes
it made to the item tree. Thus on the next execution changes weren't
reverted and server crashed on dereferencing of unallocated space.

The new helper function called is_stmt_prepare_or_first_stmt_execute
is added to the Query_arena class.
The find_field_in_view function now uses
is_stmt_prepare_or_first_stmt_execute() to check whether
newly created view items should be freed at the end of the query execution.
The Item_cond::compile function now saves changes it makes to item tree.

mysql-test/r/ps.result:
  Added a test case for the bug#48508.
mysql-test/t/ps.test:
  Added a test case for the bug#48508.
sql/item_cmpfunc.cc:
  Bug#48508: Crash on prepared statement re-execution.
  The Item_cond::compile function now saves changes it makes to item tree.
sql/sql_base.cc:
  Bug#48508: Crash on prepared statement re-execution.
  The find_field_in_view function now uses
  is_stmt_prepare_or_first_stmt_execute() to check whether
  newly created view items should be freed at the end of the query execution.
sql/sql_class.h:
  Bug#48508: Crash on prepared statement re-execution.
  The Query_arena::is_stmt_prepare_or_first_sp_execute function now correctly
  do its check.
2009-12-01 21:28:45 +03:00
Evgeny Potemkin
1db3a684e2 Bug#48508: Crash on prepared statement re-execution.
Actually there is two different bugs.
The first one caused crash on queries with WHERE condition over views
containing WHERE condition. A wrong check for prepared statement phase led
to items for view fields being allocated in the execution memory and freed
at the end of execution. Thus the optimized WHERE condition refers to
unallocated memory on the second execution and server crashed.
The second one caused by the Item_cond::compile function not saving changes
it made to the item tree. Thus on the next execution changes weren't
reverted and server crashed on dereferencing of unallocated space.

The new helper function called is_stmt_prepare_or_first_stmt_execute
is added to the Query_arena class.
The find_field_in_view function now uses
is_stmt_prepare_or_first_stmt_execute() to check whether
newly created view items should be freed at the end of the query execution.
The Item_cond::compile function now saves changes it makes to item tree.
2009-12-01 21:28:45 +03:00
Evgeny Potemkin
0039944e0c Additional fix for the bug#43668.
Arg_comparator now takes into account that some of
optimizations aren't done in the PREPARE stmt.
2009-11-25 12:52:03 +03:00
Evgeny Potemkin
28b54d144d Additional fix for the bug#43668.
Arg_comparator now takes into account that some of
optimizations aren't done in the PREPARE stmt.
2009-11-25 12:52:03 +03:00
Evgeny Potemkin
9f638f535e Manual merge of the fix for bug#43668. 2009-11-24 18:26:13 +03:00
Evgeny Potemkin
438b795ff7 Manual merge of the fix for bug#43668. 2009-11-24 18:26:13 +03:00
Konstantin Osipov
9a9e8d2311 Backport of:
----------------------------------------------------------------------
ChangeSet@1.2571, 2008-04-08 12:30:06+02:00, vvaintroub@wva. +122 -0
  Bug#32082 : definition of VOID in my_global.h conflicts with Windows
  SDK headers
  
  VOID macro is now removed. Its usage is replaced with void cast.
  In some cases, where cast does not make much sense (pthread_*, printf, 
  hash_delete, my_seek), cast is ommited.


client/mysqladmin.cc:
  Bug#32082 : remove VOID macro
client/mysqldump.c:
  Bug#32082 : remove VOID macro
client/mysqlimport.c:
  Bug#32082 : remove VOID macro
client/mysqlslap.c:
  Bug#32082 : remove VOID macro
client/mysqltest.cc:
  Bug#32082 : remove VOID macro
client/sql_string.cc:
  Bug#32082 : remove VOID macro
extra/comp_err.c:
  Bug#32082 : remove VOID macro
extra/replace.c:
  Bug#32082 : remove VOID macro
include/my_alarm.h:
  Bug#32082 : remove VOID macro
include/my_global.h:
  Bug#32082 : remove VOID macro
libmysql/libmysql.c:
  Bug#32082 : remove VOID macro
mysys/errors.c:
  Bug#32082 : remove VOID macro
mysys/hash.c:
  Bug#32082 : remove VOID macro
mysys/mf_iocache2.c:
  Bug#32082 : remove VOID macro
mysys/mf_loadpath.c:
  Bug#32082 : remove VOID macro
mysys/mf_path.c:
  Bug#32082 : remove VOID macro
mysys/my_append.c:
  Bug#32082 : remove VOID macro
mysys/my_clock.c:
  Bug#32082 : remove VOID macro
mysys/my_copy.c:
  Bug#32082 : remove VOID macro
mysys/my_fstream.c:
  Bug#32082 : remove VOID macro
mysys/my_getwd.c:
  Bug#32082 : remove VOID macro
mysys/my_lib.c:
  Bug#32082 : remove VOID macro
mysys/my_lockmem.c:
  Bug#32082 : remove VOID macro
mysys/my_pthread.c:
  Bug#32082 : remove VOID macro
mysys/my_redel.c:
  Bug#32082 : remove VOID macro
mysys/stacktrace.c:
  Bug#32082 : remove VOID macro
mysys/thr_alarm.c:
  Bug#32082 : remove VOID macro
mysys/thr_lock.c:
  Bug#32082 : remove VOID macro
sql/derror.cc:
  Bug#32082 : remove VOID macro
sql/des_key_file.cc:
  Bug#32082 : remove VOID macro
sql/discover.cc:
  Bug#32082 : remove VOID macro
sql/field.cc:
  Bug#32082 : remove VOID macro
sql/filesort.cc:
  Bug#32082 : remove VOID macro
sql/ha_ndbcluster.cc:
  Bug#32082 : remove VOID macro
sql/ha_partition.cc:
  Bug#32082 : remove VOID macro
sql/handler.cc:
  Bug#32082 : remove VOID macro
sql/hostname.cc:
  Bug#32082 : remove VOID macro
sql/init.cc:
  Bug#32082 : remove VOID macro
sql/item.cc:
  Bug#32082 : remove VOID macro
sql/item_cmpfunc.cc:
  Bug#32082 : remove VOID macro
sql/item_strfunc.cc:
  Bug#32082 : remove VOID macro
sql/lock.cc:
  Bug#32082 : remove VOID macro
sql/log.cc:
  Bug#32082 : remove VOID macro
sql/log_event.cc:
  Bug#32082 : remove VOID macro
sql/mysqld.cc:
  Bug#32082 : remove VOID macro
sql/opt_range.h:
  Bug#32082 : remove VOID macro
sql/protocol.cc:
  Bug#32082 : remove VOID macro
sql/records.cc:
  Bug#32082 : remove VOID macro
sql/sp_head.cc:
  Bug#32082 : remove VOID macro
sql/sp_pcontext.cc:
  Bug#32082 : remove VOID macro
sql/sql_acl.cc:
  Bug#32082 : remove VOID macro
sql/sql_base.cc:
  Bug#32082 : remove VOID macro
sql/sql_cache.cc:
  Bug#32082 : remove VOID macro
sql/sql_connect.cc:
  Bug#32082 : remove VOID macro
sql/sql_db.cc:
  Bug#32082 : remove VOID macro
sql/sql_delete.cc:
  Bug#32082 : remove VOID macro
sql/sql_handler.cc:
  Bug#32082 : remove VOID macro
sql/sql_insert.cc:
  Bug#32082 : remove VOID macro
sql/sql_map.cc:
  Bug#32082 : remove VOID macro
sql/sql_parse.cc:
  Bug#32082 : remove VOID macro
sql/sql_select.cc:
  Bug#32082 : remove VOID macro
sql/sql_servers.cc:
  Bug#32082 : remove VOID macro
sql/sql_show.cc:
  Bug#32082 : remove VOID macro
sql/sql_string.cc:
  Bug#32082 : remove VOID macro
sql/sql_table.cc:
  Bug#32082 : remove VOID macro
sql/sql_test.cc:
  Bug#32082 : remove VOID macro
sql/sql_trigger.cc:
  Bug#32082 : remove VOID macro
sql/sql_update.cc:
  Bug#32082 : remove VOID macro
sql/sql_view.cc:
  Bug#32082 : remove VOID macro
sql/table.cc:
  Bug#32082 : remove VOID macro
sql/tztime.cc:
  Bug#32082 : remove VOID macro
sql/udf_example.c:
  Bug#32082 : remove VOID macro
sql/uniques.cc:
  Bug#32082 : remove VOID macro
sql/unireg.cc:
  Bug#32082 : remove VOID macro
storage/archive/ha_archive.cc:
  Bug#32082 : remove VOID macro
storage/blackhole/ha_blackhole.cc:
  Bug#32082 : remove VOID macro
storage/csv/ha_tina.cc:
  Bug#32082 : remove VOID macro
storage/csv/transparent_file.cc:
  Bug#32082 : remove VOID macro
storage/example/ha_example.cc:
  Bug#32082 : remove VOID macro
storage/federated/ha_federated.cc:
  Bug#32082 : remove VOID macro
storage/heap/hp_clear.c:
  Bug#32082 : remove VOID macro
storage/heap/hp_create.c:
  Bug#32082 : remove VOID macro
storage/heap/hp_test1.c:
  Bug#32082 : remove VOID macro
storage/heap/hp_test2.c:
  Bug#32082 : remove VOID macro
storage/innobase/handler/ha_innodb.cc:
  Bug#32082 : remove VOID macro
storage/myisam/ft_eval.c:
  Bug#32082 : remove VOID macro
storage/myisam/ha_myisam.cc:
  Bug#32082 : remove VOID macro
storage/myisam/mi_changed.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_check.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_close.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_create.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_dbug.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_delete.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_delete_all.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_dynrec.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_info.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_locking.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_log.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_open.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_packrec.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_panic.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_rsame.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_statrec.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_test1.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_test2.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_test3.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_update.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_write.c:
  Bug#32082 : remove VOID macro
storage/myisam/myisamchk.c:
  Bug#32082 : remove VOID macro
storage/myisam/myisamlog.c:
  Bug#32082 : remove VOID macro
storage/myisam/myisampack.c:
  Bug#32082 : remove VOID macro
storage/myisam/sort.c:
  Bug#32082 : remove VOID macro
storage/myisammrg/myrg_close.c:
  Bug#32082 : remove VOID macro
storage/myisammrg/myrg_create.c:
  Bug#32082 : remove VOID macro
storage/myisammrg/myrg_open.c:
  Bug#32082 : remove VOID macro
strings/str_test.c:
  Bug#32082 : remove VOID macro
tests/thread_test.c:
  Bug#32082 : remove VOID macro
2009-11-24 16:54:59 +03:00
Konstantin Osipov
4cff617c25 Backport of:
----------------------------------------------------------------------
ChangeSet@1.2571, 2008-04-08 12:30:06+02:00, vvaintroub@wva. +122 -0
  Bug#32082 : definition of VOID in my_global.h conflicts with Windows
  SDK headers
  
  VOID macro is now removed. Its usage is replaced with void cast.
  In some cases, where cast does not make much sense (pthread_*, printf, 
  hash_delete, my_seek), cast is ommited.
2009-11-24 16:54:59 +03:00
Davi Arnaut
5aeeaaf507 Manual merge of mysql-next-mr-runtime upstream. 2009-11-19 21:48:08 -02:00
Davi Arnaut
ecb6228c62 Manual merge of mysql-next-mr-runtime upstream. 2009-11-19 21:48:08 -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
Evgeny Potemkin
726e83907c 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.
2009-11-17 17:06:46 +03:00
unknown
a962160eec Merge with MySQL 5.1, with following additions:
- Moved some code from innodb_plugin to xtradb, to ensure that all tests runs
- Did changes in pbxt and maria storage engines becasue of changes in thd->query
- Reverted wrong code in sql_table.cc for how ROW_FORMAT is used.

This is a re-commit of Monty's merge to eliminate an extra commit from
MySQL-5.1.42 that was accidentally included in the merge.

This is a merge of the MySQL 5.1.41 clone-off (clone-5.1.41-build). In
case there are any extra changes done before final MySQL 5.1.41
release, these will need to be merged later before MariaDB 5.1.41
release.
2009-11-16 21:49:51 +01: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
Evgeny Potemkin
60d358af27 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.
2009-11-06 22:34:25 +03:00
Magne Mahre
a5d74eb1b4 Bug#42664: Sign ignored for TIME types when not comparing as longlong
Another code-path dropped sign of TIME, presuming all time is positive.
      
Minds sign now. Patch depends on ChangeSet for 42661.


mysql-test/r/type_time.result:
  Show we now no longer ignore sign of TIME-type
  in this code-path.
mysql-test/t/type_time.test:
  Show we now no longer ignore sign of TIME-type
  in this code-path.
sql/item_cmpfunc.cc:
  TIME_to_ulonglong() (somewhat obviously) loses sign
  of its argument, so we put it back in where needed.
2009-11-04 11:28:50 +01:00
Magne Mahre
948bb3e6dc Bug#42664: Sign ignored for TIME types when not comparing as longlong
Another code-path dropped sign of TIME, presuming all time is positive.
      
Minds sign now. Patch depends on ChangeSet for 42661.
2009-11-04 11:28:50 +01:00
Jorgen Loland
bec35067d3 Bug#48177 - SELECTs with NOT IN subqueries containing NULL
values return too many records

WHERE clauses with "outer_value_list NOT IN subselect" were
handled incorrectly if the outer value list contained multiple 
items where at least one of these could be NULL. The first 
outer record with NULL value was handled correctly, but if a 
second record with NULL value existed, the optimizer would 
choose to reuse the result it got on the last execution of the 
subselect. This is incorrect if the outer value list has 
multiple items.
     
The fix is to make Item_in_optimizer::val_int (in 
item_cmpfunc.cc) reuse the result of the latest execution
for NULL values only if all values in the outer_value_list 
are NULL.


mysql-test/r/subselect3.result:
  Added test for BUG#48177
mysql-test/t/subselect3.test:
  Added test for BUG#48177
sql/item_cmpfunc.cc:
  Make Item_in_optimizer::val_int (in item_cmpfunc.cc) reuse the result of the latest execution for NULL values only if all values in the outer_value_list are NULL.
2009-11-03 13:48:59 +01:00
Jorgen Loland
7f9a504745 Bug#48177 - SELECTs with NOT IN subqueries containing NULL
values return too many records

WHERE clauses with "outer_value_list NOT IN subselect" were
handled incorrectly if the outer value list contained multiple 
items where at least one of these could be NULL. The first 
outer record with NULL value was handled correctly, but if a 
second record with NULL value existed, the optimizer would 
choose to reuse the result it got on the last execution of the 
subselect. This is incorrect if the outer value list has 
multiple items.
     
The fix is to make Item_in_optimizer::val_int (in 
item_cmpfunc.cc) reuse the result of the latest execution
for NULL values only if all values in the outer_value_list 
are NULL.
2009-11-03 13:48:59 +01: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
Davi Arnaut
9a08362897 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
f539e0c825 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.
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
Georgi Kodinov
43d7fb43cd Bug #46175: NULL read_view and consistent read assertion
The SE API requires mysql to notify the storage engine that
it's going to read certain tables at the beginning of the 
statement (by calling start_stmt(), store_lock() or
external_lock()).
These are typically called by the lock_tables(). 
However SHOW CREATE TABLE is not pre-locking the tables
because it's not expected to access the data at all.
But for some view definitions (that include comparing a
date/datetime/timestamp column to a string returning
scalar subquery) the JOIN::prepare may still access data
when materializing the scalar non-correlated subquery
in Arg_comparator::can_compare_as_dates().
Fixed by not materializing the subquery when the function
is called in a SHOW/EXPLAIN/CREATE VIEW
2009-11-04 13:54:28 +02:00
Evgeny Potemkin
47d850a89d Auto-merged fix for the bug#34384. 2009-11-06 22:42:24 +03:00
Georgi Kodinov
9ba74e5d21 Bug #46175: NULL read_view and consistent read assertion
The SE API requires mysql to notify the storage engine that
it's going to read certain tables at the beginning of the 
statement (by calling start_stmt(), store_lock() or
external_lock()).
These are typically called by the lock_tables(). 
However SHOW CREATE TABLE is not pre-locking the tables
because it's not expected to access the data at all.
But for some view definitions (that include comparing a
date/datetime/timestamp column to a string returning
scalar subquery) the JOIN::prepare may still access data
when materializing the scalar non-correlated subquery
in Arg_comparator::can_compare_as_dates().
Fixed by not materializing the subquery when the function
is called in a SHOW/EXPLAIN/CREATE VIEW
2009-11-04 13:54:28 +02:00
unknown
6aad537a6a Merge MySQL 5.1.39 into MariaDB 5.1. 2009-10-15 23:38:29 +02:00
Gleb Shchepa
33cd911a16 Bug #44139: Table scan when NULL appears in IN clause
SELECT ... WHERE ... IN (NULL, ...) does full table scan,
even if the same query without the NULL uses efficient range scan.

The bugfix for the bug 18360 introduced an optimization:
if
  1) all right-hand arguments of the IN function are constants
  2) result types of all right argument items are compatible
     enough to use the same single comparison function to
     compare all of them to the left argument,

then

  we can convert the right-hand list of constant items to an array
  of equally-typed constant values for the further
  QUICK index access etc. (see Item_func_in::fix_length_and_dec()).

The Item_null constant item objects have STRING_RESULT
result types, so, as far as Item_func_in::fix_length_and_dec()
is aware of NULLs in the right list, this improvement efficiently
optimizes IN function calls with a mixed right list of NULLs and
string constants. However, the optimization doesn't affect mixed
lists of NULLs and integers, floats etc., because there is no
unique common comparator.


New optimization has been added to ignore the result type
of NULL constants in the static analysis of mixed right-hand lists.
This is safe, because at the execution phase we care about
presence of NULLs anyway.

1. The collect_cmp_types() function has been modified to optionally
   ignore NULL constants in the item list.
2. NULL-skipping code of the Item_func_in::fix_length_and_dec()
   function has been modified to work not only with in_string
   vectors but with in_vectors of other types.


mysql-test/r/func_in.result:
  Added test case for the bug #44139.
mysql-test/t/func_in.test:
  Added test case for the bug #44139.
sql/item_cmpfunc.cc:
  Bug #44139: Table scan when NULL appears in IN clause
  
  1. The collect_cmp_types() function has been modified to optionally
     ignore NULL constants in the item list.
  2. NULL-skipping code of the Item_func_in::fix_length_and_dec()
     function has been modified to work not only with in_string
     vectors but with in_vectors of other types.
2009-10-05 10:27:36 +05:00
Gleb Shchepa
2b78dbff54 Bug #44139: Table scan when NULL appears in IN clause
SELECT ... WHERE ... IN (NULL, ...) does full table scan,
even if the same query without the NULL uses efficient range scan.

The bugfix for the bug 18360 introduced an optimization:
if
  1) all right-hand arguments of the IN function are constants
  2) result types of all right argument items are compatible
     enough to use the same single comparison function to
     compare all of them to the left argument,

then

  we can convert the right-hand list of constant items to an array
  of equally-typed constant values for the further
  QUICK index access etc. (see Item_func_in::fix_length_and_dec()).

The Item_null constant item objects have STRING_RESULT
result types, so, as far as Item_func_in::fix_length_and_dec()
is aware of NULLs in the right list, this improvement efficiently
optimizes IN function calls with a mixed right list of NULLs and
string constants. However, the optimization doesn't affect mixed
lists of NULLs and integers, floats etc., because there is no
unique common comparator.


New optimization has been added to ignore the result type
of NULL constants in the static analysis of mixed right-hand lists.
This is safe, because at the execution phase we care about
presence of NULLs anyway.

1. The collect_cmp_types() function has been modified to optionally
   ignore NULL constants in the item list.
2. NULL-skipping code of the Item_func_in::fix_length_and_dec()
   function has been modified to work not only with in_string
   vectors but with in_vectors of other types.
2009-10-05 10:27:36 +05:00
Sergey Petrunya
d762bf21cc MWL#17: Table-elimination
- Addressing review feedback, generation 4.

include/my_global.h:
  Make ALIGN_PTR's action correspond to that of ALIGN_SIZE
sql/item.cc:
  MWL#17: Table-elimination
  - Review feedback: function renames, better comments
sql/item.h:
  MWL#17: Table-elimination
  - Review feedback: function renames, better comments
sql/item_cmpfunc.cc:
  MWL#17: Table-elimination
  - Review feedback: function renames, better comments
sql/item_subselect.cc:
  MWL#17: Table-elimination
  - Review feedback: function renames, better comments
sql/item_subselect.h:
  MWL#17: Table-elimination
  - Review feedback: function renames, better comments
sql/opt_table_elimination.cc:
  MWL#17: Table-elimination
  - Addressing review feedback, generation 4: abstract everything in case
    we would need to change it for something else in the future.
sql/sql_list.h:
  MWL#17: Table-elimination
  - Introduce exchange_sort(List<T> ...) template function
sql/sql_select.cc:
  MWL#17: Table-elimination
  - Review feedback: function renames, better comments
2009-09-01 00:02:09 +04:00
Staale Smedseng
5be4c38226 Merge from 5.0 for 43414 2009-08-28 18:21:54 +02:00
Staale Smedseng
f59ef9eafa 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
Staale Smedseng
2217de2513 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.
2009-08-28 17:51:31 +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
Davi Arnaut
31afccc407 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.
2009-08-24 16:47:08 -03:00
Alexey Kopytov
2d4df13ef2 Manual merge. 2009-07-03 14:36:04 +04:00