Commit graph

173 commits

Author SHA1 Message Date
Sergey Glukhov
bdefd2ad3b 5.1 -> 5.5 merge 2011-04-12 14:13:15 +04:00
Sergey Glukhov
7fa7a0cad9 Bug#11766270 59343: YEAR(4): INCORRECT RESULT AND VALGRIND WARNINGS WITH MIN/MAX, UNION
When we create temporary result table for UNION
incorrect max_length for YEAR field is used and
it leads to incorrect field value and incorrect
result string length as YEAR field value calculation
depends on field length.
The fix is to use underlying item max_length for
Item_sum_hybrid::max_length intialization.


mysql-test/r/func_group.result:
  test case
mysql-test/t/func_group.test:
  test case
sql/field.cc:
  added assert
sql/item_sum.cc:
  init Item_sum_hybrid::max_length with 
  use underlying item max_length for
  INT result type.
2011-04-12 14:01:33 +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
Tor Didriksen
b503d77d5c Backport of fix for Bug#52123 2011-02-02 10:18:44 +01:00
Sergey Glukhov
9870e24482 test case fix 2010-12-21 15:30:07 +03:00
Sergey Glukhov
928f52e1c1 5.1-bugteam->5.5-bugteam merge 2010-12-21 15:32:15 +03:00
Sergey Glukhov
41f17a8707 5.1-bugteam->5.5-bugteam merge 2010-12-21 14:50:03 +03:00
Sergey Glukhov
e2db8e6ccb Bug#58030 crash in Item_func_geometry_from_text::val_str
Item_sum_max/Item_sum_min incorrectly set null_value flag and
attempt to get result in parent functions leads to crash.
This happens due to double evaluation of the function argumet.
First evaluation happens in the comparator and second one
happens in Item_cache::cache_value().
The fix is to introduce new Item_cache object which
holds result of the argument and use this cached value
as an argument of the comparator.

mysql-test/r/func_group.result:
  test case
mysql-test/t/func_group.test:
  test case
sql/item.cc:
  added assertion that ether we have some result or result is NULL.
sql/item_sum.cc:
  introduce new Item_cache object which
  holds result of the argument and use this cached value
  as an argument of the comparator.
sql/item_sum.h:
  introduce new Item_cache object which
  holds result of the argument and use this cached value
  as an argument of the comparator.
2010-12-21 14:34:11 +03:00
Guilhem Bichot
39b0af1e8c Fix for Bug#57932 "query with avg returns incorrect results":
when there was one NULL value, AVG(DISTINCT) could forget about other values.
See commit comment of item_sum.cc.

mysql-test/r/func_group.result:
  before the code fix, both SELECTs would return NULL
sql/item_sum.cc:
  Assume we are executing "SELECT AVG([DISTINCT] some_field) FROM some_table".
  and some_field is the single field of some_table for simplicity.
  Each time a row is processed (evaluate_join_record()->
  end_send_group()->update_sum_func()) an aggregator is notified,
  which itself notifies an Item_sum_avg.
  Without DISTINCT, this Item_sum_avg immediately increments its
  internal "sum of values" and "count of values" (the latter being
  Item_sum_avg::count). The count is incremented only if the row's value
  is not NULL (in Item_sum_avg::add()), per AVG() semantices. This row's value
  is available in args[0] of Item_sum_avg ("args[0]" stands for
  "the first argument of the item": it's an Item_field which automatically
  receives the row's value when a row is read from the table).
  bool Item_sum_avg::add()
  {
    if (Item_sum_sum::add()) << calculates the sum (ignores NULL)
      return TRUE;
    if (!args[0]->null_value)<<if added value is not NULL
      count++;       <<increment "count"
    return FALSE;
  }
  and everything works.
  With DISTINCT, when a row is processed by evaluate_join_record(),
  Item_sum_avg does no immediate computation, rather stores
  the row's value in a tree (to throw the value away if it is a duplicate
  of previous value, otherwise to remember all
  distinct values). It's only when it's time to send the average to the
  user (at end of the query:
  sub_select(end_of_records=true)->end_send_group()->
  select_send->send_data()->Protocol::send_result_set_row()->
  Item::send()->Item_sum_avg->val_str()), that we iterate over the tree,
  compute the sum and count: for this, for each element of the tree,
  Item_sum_avg::add() is called and has the same two steps as before:
  * Item_sum_sum::add() updates the sum (finding the tree element's value
  correctly, and determining correctly its NULLness - look for "arg_is_null"
  in that function)
  * the "if (!args[0]->null_value)" test right after, breaks: it uses args[0],
  which isn't the tree's element but rather the value for the last row
  processed by evaluate_join_record(). So if that last row was NULL,
  "count" stays 0 for each row, and AVG() then returns NULL (count==0 =>
  NULL, per AVG() semantics).
  The fix is to let the aggregator tell whether the value
  it just saw was NULL. The aggregator knows where to get the info
  thanks to virtual functions. Item_sum_sum::add() now asks
  the aggregator. Item_sum_avg() also asks the aggregator
  and then knows it shouldn't increment "count".
sql/item_sum.h:
  Aggregator can now tell about value/NULLness of just-aggregated value
2010-12-07 16:59:32 +01:00
Alexander Nozdrin
9ab0759ea4 Auto-merge from mysql-5.5. 2010-08-30 12:36:02 +04:00
Alexey Kopytov
4124f1f467 Automerge. 2010-08-30 11:36:04 +04:00
Alexey Kopytov
d7d0f6390b Bug #54465: assert: field_types == 0 || field_types[field_pos]
== MYSQL_TYPE_LONGLONG

A MIN/MAX() function with a subquery as its argument could lead
to a debug assertion on debug builds or wrong data on release
ones.

The problem was a combination of the following factors:

- Item_sum_hybrid::fix_fields() might use the argument
(args[0]) to calculate 'hybrid_field_type' which was later used
to decide how the data should be sent to the client.

- Item_sum::make_field() might use the argument again to
calculate the field's type when sending result set metadata to
the client.

- The argument could be changed in between these two calls via
  Item::set_arg() leading to inconsistent metadata being
  reported.

Here is what was happening for the bug's test case:

1. Item_sum_hybrid::fix_fields() calculates hybrid_field_type
as MYSQL_TYPE_LONGLONG based on args[0] which is an
Item::SUBSELECT_ITEM at that time.

2. A temporary table is created to execute the
query. create_tmp_field_from_item() creates a Field_long object
according to the subselect's max_length.

3. The subselect item in Item_sum_hybrid is replaced by the
Item_field object referencing the newly created Field_long.

4. Item_sum::make_field() rightfully returns the
MYSQL_TYPE_LONG type when calculating the result set metadata.

5. When sending the actual data, Item::send() relies on the
virtual field_type() function which in our case returns
previously calculated hybrid_field_type == MYSQL_TYPE_LONGLONG.

It looks like the only solution is to never refer to the
argument's metadata after the result metadata has been
calculated in fix_fields(), since the argument itself may be
different by then. In this sense, Item_sum::make_field() should
never be used, because it may rely on the argument's metadata
and is only called after fix_fields(). The "default"
implementation in Item::make_field() should be used instead as
it relies only on field_type(), but not on the argument's type.

Fixed by removing Item_sum::make_field() so that the superclass
implementation Item::make_field() is always used.

mysql-test/r/func_group.result:
  Added a test case for bug #54465.
mysql-test/t/func_group.test:
  Added a test case for bug #54465.
sql/item_sum.cc:
  Removed Item_sum::make_field() so that the superclass
  implementation Item::make_field() is always used.
sql/item_sum.h:
  Removed Item_sum::make_field() so that the superclass
  implementation Item::make_field() is always used.
2010-08-27 13:44:35 +04:00
Evgeny Potemkin
dd1890f48c Bug#56120: Failed assertion on MIX/MAX on negative time value
The Item_cache_datetime::val_str function wasn't taking into account that time
could be negative. This led to failed assertion.
Now Item_cache_datetime::val_str correctly converts negative time values
from integer to string representation.

mysql-test/r/func_group.result:
  Added a test case for the bug#56120.
mysql-test/t/func_group.test:
  Added a test case for the bug#56120.
sql/item.cc:
  Bug#56120: Failed assertion on MIX/MAX on negative time value
  Now Item_cache_datetime::val_str correctly converts negative time values
  from integer to string representation.
2010-08-23 19:59:56 +04:00
Evgeny Potemkin
8147199f62 Bug#55648: Server crash on MIX/MAX on maximum time value
A typo in the Item_cache_datetime::val_str caused an assertion to fail on the
maximum time value.


mysql-test/r/func_group.result:
  A test case for the bug#55648.
mysql-test/t/func_group.test:
  A test case for the bug#55648.
sql/item.cc:
  Bug#55648: Server crash on MIX/MAX on maximum time value
  Corrected assertion.
2010-08-02 16:36:41 +04:00
Alexey Kopytov
12f364ece7 Backport of WL #2934: Make/find library for doing float/double
to string conversions and vice versa" 
Initial import of the dtoa.c code and custom wrappers around it 
to allow its usage from the server code. 
 
Conversion of FLOAT/DOUBLE values to DECIMAL ones or strings 
and vice versa has been significantly reworked. As the new 
algoritms are more precise than the older ones, results of such 
conversions may not always match those obtained from older 
server versions. This in turn may break compatibility for some 
applications. 
 
This patch also fixes the following bugs: 
- bug #12860 "Difference in zero padding of exponent between 
Unix and Windows" 
- bug #21497 "DOUBLE truncated to unusable value" 
- bug #26788 "mysqld (debug) aborts when inserting specific 
numbers into char fields" 
- bug #24541 "Data truncated..." on decimal type columns 
without any good reason"
2009-12-22 19:23:13 +03:00
Evgeny Potemkin
9f638f535e Manual merge of the fix for bug#43668. 2009-11-24 18:26:13 +03: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
Jorgen Loland
6da93b223b Bug#47280 - strange results from count(*) with order by multiple
columns without where/group
                     
Simple SELECT with implicit grouping used to return many rows if
the query was ordered by the aggregated column in the SELECT
list. This was incorrect because queries with implicit grouping
should only return a single record.
                              
The problem was that when JOIN:exec() decided if execution needed
to handle grouping, it was assumed that sum_func_count==0 meant
that there were no aggregate functions in the query. This
assumption was not correct in JOIN::exec() because the aggregate
functions might have been optimized away during JOIN::optimize().
                  
The reason why queries without ordering behaved correctly was
that sum_func_count is only recalculated if the optimizer chooses
to use temporary tables (which it does in the ordered case).
Hence, non-ordered queries were correctly treated as grouped.
                  
The fix for this bug was to remove the assumption that
sum_func_count==0 means that there is no need for grouping. This
was done by introducing variable "bool implicit_grouping" in the
JOIN object.

mysql-test/r/func_group.result:
  Add test for BUG#47280
mysql-test/t/func_group.test:
  Add test for BUG#47280
sql/opt_sum.cc:
  Improve comment for opt_sum_query()
sql/sql_class.h:
  Add comment for variables in TMP_TABLE_PARAM
sql/sql_select.cc:
  Introduce and use variable implicit_grouping instead of (!group_list && sum_func_count) in places that need to test if grouping is required. Also added comments for: optimization of aggregate fields for implicitly grouped queries  (JOIN::optimize) and choice of end_select method (JOIN::execute)
sql/sql_select.h:
  Add variable implicit_grouping, which will be TRUE for queries that contain aggregate functions but no GROUP BY clause. Also added comment to sort_and_group variable.
2009-10-14 10:46:50 +02:00
Alexey Kopytov
1571f06196 Merge into dev tree. 2009-02-10 16:27:35 +03:00
Alexey Kopytov
a01946373d Fix for bug #21205: Different number of digits for float/double/real in --ps-protocol
Various parts of code used different 'precision' arguments for sprintf("%g") when converting
floating point numbers to a string. This led to differences in results in some cases 
depending on whether the text-based or prepared statements protocol is used for a query.

Fixed by changing arguments to sprintf("%g") to always be 15 (DBL_DIG) so that results are
consistent regardless of the protocol.

This patch will be null-merged to 6.0 as the problem does not exists there (fixed by the
patch for WL#2934).

client/sql_string.cc:
  Use 15 (DBL_DIG) as a precision argument for sprintf(), as Field_double::val_str() does.
libmysql/libmysql.c:
  Use 15 (DBL_DIG) as a precision argument for sprintf(), as Field_double::val_str() does.
mysql-test/r/archive_gis.result:
  Fixed test results to take additional precision into account.
mysql-test/r/func_group.result:
  Fixed test results to take additional precision into account.
mysql-test/r/func_math.result:
  Fixed test results to take additional precision into account.
mysql-test/r/func_str.result:
  Fixed test results to take additional precision into account.
mysql-test/r/gis.result:
  Fixed test results to take additional precision into account.
mysql-test/r/innodb_gis.result:
  Fixed test results to take additional precision into account.
mysql-test/r/select.result:
  Fixed test results to take additional precision into account.
mysql-test/r/sp.result:
  Fixed test results to take additional precision into account.
mysql-test/r/type_float.result:
  Fixed test results to take additional precision into account.
mysql-test/t/type_float.test:
  Fixed test results to take additional precision into account.
sql/sql_string.cc:
  Use 15 (DBL_DIG) as a precision argument for sprintf(), as Field_double::val_str() does.
2009-01-28 20:59:08 +03:00
Georgi Kodinov
f31d305238 merged bug 39656 to 5.1-bugteam 2008-11-24 18:00:09 +02:00
Georgi Kodinov
d795963cba Bug #39656: Behaviour different for agg functions with & without where -
ONLY_FULL_GROUP_BY

The check for non-aggregated columns in queries with aggregate function, but without
GROUP BY was treating all the parts of the query as if they are in the SELECT list.
Fixed by ignoring the non-aggregated fields in the WHERE clause.

mysql-test/r/func_group.result:
  Bug #39656: test case
mysql-test/t/func_group.test:
  Bug #39656: test case
sql/sql_select.cc:
  Bug #39656: ignore the new non-aggregated column refs in a WHERE
  by saving the state so far and then adding only the new values of the other
  parts of the bitmask.
2008-11-24 17:30:47 +02:00
Georgi Kodinov
a18639b634 Bug #37348: Crash in or immediately after JOIN::make_sum_func_list
The optimizer pulls up aggregate functions which should be aggregated in
an outer select. At some point it may substitute such a function for a field
in the temporary table. The setup_copy_fields function doesn't take this
into account and may overrun the copy_field buffer.
      
Fixed by filtering out the fields referenced through the specialized
reference for aggregates (Item_aggregate_ref).
Added an assertion to make sure bugs that cause similar discrepancy 
don't go undetected.

mysql-test/r/func_group.result:
  Bug #37348: test case
mysql-test/t/func_group.test:
  Bug #37348: test case
sql/item.cc:
  Bug #37348: Added a way to distinguish Item_aggregate_ref from the other types of refs
sql/item.h:
  Bug #37348: Added a way to distinguish Item_aggregate_ref from the other types of refs
sql/sql_select.cc:
  Bug #37348: 
   - Don't consider copying field references
      seen through Item_aggregate_ref
   - check for discrepancies between the number of expected 
     fields that need copying and the actual fields copied.
2008-10-02 17:44:49 +03:00
unknown
e829d36367 Merge kaamos.(none):/data/src/opt/bug34512/my50
into  kaamos.(none):/data/src/opt/bug34512/my51


mysql-test/r/func_group.result:
  Auto merged
mysql-test/t/func_group.test:
  Auto merged
sql/item_sum.cc:
  Auto merged
2008-03-19 14:25:36 +03:00
unknown
8270d9875f Fix for bug #34512: CAST( AVG( double ) AS DECIMAL )
returns wrong results

Casting AVG() to DECIMAL led to incorrect results when the arguments
had a non-DECIMAL type, because in this case
Item_sum_avg::val_decimal() performed the division by the number of
arguments twice.

Fixed by changing Item_sum_avg::val_decimal() to not rely on
Item_sum_sum::val_decimal(), i.e. calculate sum and divide using
DECIMAL arithmetics for DECIMAL arguments, and utilize val_real() with
subsequent conversion to DECIMAL otherwise.


mysql-test/r/func_group.result:
  Added a test case for bug #34512.
mysql-test/t/func_group.test:
  Added a test case for bug #34512.
sql/item_sum.cc:
  Do not use Item_sum_sum::val_decimal() in Item_sum_avg::val_decimal()
  because the first one, depending on the arguments type, may return
  either the sum of the arguments, or the average calculated by the
  virtual val_real() method of Item_sum_avg. Instead, do our own
  calculation based on the arguments type.
2008-03-06 18:19:47 +03:00
unknown
d12cc6e066 merge of the fix for bug 33133 to 5.1-opt 2008-01-09 18:00:12 +02:00
unknown
e2584c9fa0 Merge macbook.gmz:/Users/kgeorge/mysql/work/B33133-5.0-opt
into  macbook.gmz:/Users/kgeorge/mysql/work/B33133-5.1-opt


mysql-test/r/func_group.result:
  Auto merged
mysql-test/t/func_group.test:
  Auto merged
sql/sql_base.cc:
  Auto merged
2008-01-09 17:10:09 +02:00
unknown
06b68454ea Bug #33133: Views are not transparent
When resolving references we need to take into consideration
the view "fields" and allow qualified access to them.
Fixed by extending the reference resolution to process view
fields correctly.


mysql-test/r/func_group.result:
  Bug #33133: test case
mysql-test/t/func_group.test:
  Bug #33133: test case
sql/sql_base.cc:
  Bug #33133: allow qualified alias refs to view fields
2008-01-09 16:49:13 +02:00
unknown
4cb4a53eb4 Merge magare.gmz:/home/kgeorge/mysql/work/B31794-5.0-opt
into  magare.gmz:/home/kgeorge/mysql/work/B31794-5.1-opt


mysql-test/r/func_group.result:
  Auto merged
mysql-test/t/func_group.test:
  Auto merged
sql/sql_select.cc:
  Auto merged
2007-11-01 18:49:45 +02:00
unknown
660eb5bb40 Bug #31794: no syntax error on SELECT id FROM t HAVING count(*)>2
The HAVING clause is subject to the same rules as the SELECT list
about using aggregated and non-aggregated columns.
But this was not enforced when processing implicit grouping from
using aggregate functions.
Fixed by performing the same checks for HAVING as for SELECT.


mysql-test/r/func_group.result:
  Bug #31794: test case
mysql-test/t/func_group.test:
  Bug #31794: test case
sql/sql_select.cc:
  Bug #31794: Check HAVING in addition to SELECT list
2007-11-01 18:36:24 +02:00
unknown
ee8ab6d9e6 Merge magare.gmz:/home/kgeorge/mysql/work/B30715-merged-5.0-opt
into  magare.gmz:/home/kgeorge/mysql/work/B30715-merged-5.1-opt


mysql-test/r/func_group.result:
  Auto merged
mysql-test/r/type_decimal.result:
  Auto merged
mysql-test/t/func_group.test:
  Auto merged
mysql-test/t/type_decimal.test:
  Auto merged
sql/item.cc:
  Auto merged
sql/opt_sum.cc:
  merge bug 30715 to 5.1-opt
2007-10-24 11:50:09 +03:00
unknown
e2433cbcaa Bug #30715: Assertion failed: item_field->field->real_maybe_null(),
file .\opt_sum.cc, line
The optimizer pre-calculates the MIN/MAX values for queries like
 SELECT MIN(kp_k) WHERE kp_1 = const AND ... AND kp_k-1 = const
when there is a key over kp_1...kp_k
In doing so it was not checking correctly nullability and 
there was a superfluous assert(). 
Fixed by making sure that the field can be null before checking and
taking out the wrong assert().
.
Introduced a correct check for nullability 
The MIN(field) can return NULL when all the row values in the group
are NULL-able or if there were no rows.
Fixed the assertion to reflect the case when there are no rows.


mysql-test/r/func_group.result:
  Bug #30715: test case
mysql-test/t/func_group.test:
  Bug #30715: test case
sql/opt_sum.cc:
  Bug #30715: correct nullability check for MIN/MAX pre-calculation over index.
2007-10-24 11:15:08 +03:00
unknown
c62aa5c795 Merge magare.gmz:/home/kgeorge/mysql/autopush/B31156-5.0-opt
into  magare.gmz:/home/kgeorge/mysql/work/B31156-5.1-opt


mysql-test/r/func_group.result:
  Auto merged
mysql-test/t/func_group.test:
  Auto merged
sql/item_cmpfunc.cc:
  Auto merged
sql/item_sum.cc:
  Auto merged
2007-10-13 09:22:37 +03:00
unknown
6736d404a0 Bug #31156: mysqld: item_sum.cc:918: virtual bool
Item_sum_distinct::setup(THD*): Assertion

There was an assertion to detect a bug in ROLLUP
implementation. However the assertion is not true
when used in a subquery context with non-cacheable
statements.
Fixed by turning the assertion to accepted case
(just like it's done for the other aggregate functions). 


mysql-test/r/func_group.result:
  Bug #31156: test case
mysql-test/t/func_group.test:
  Bug #31156: test case
sql/item_sum.cc:
  Bug #31156: make it OK to call setup() several times:
   done for (e.g.) scalar subquery
2007-10-08 12:57:43 +03:00
unknown
aff34a8c64 Bug #27531: 5.1 part of the fix
- Renamed "Using join cache" to "Using join buffer".
- "Using join buffer" is now printed on the last
  table that "reads" from the join buffer cache.


mysql-test/r/archive_gis.result:
  Bug #27531: renamed "Using join cache" to "Using join buffer"
  and moved to the last table in the batch.
mysql-test/r/compress.result:
  Bug #27531: renamed "Using join cache" to "Using join buffer"
  and moved to the last table in the batch.
mysql-test/r/ctype_utf8.result:
  Bug #27531: renamed "Using join cache" to "Using join buffer"
  and moved to the last table in the batch.
mysql-test/r/derived.result:
  Bug #27531: renamed "Using join cache" to "Using join buffer"
  and moved to the last table in the batch.
mysql-test/r/distinct.result:
  Bug #27531: renamed "Using join cache" to "Using join buffer"
  and moved to the last table in the batch.
mysql-test/r/func_group.result:
  Bug #27531: renamed "Using join cache" to "Using join buffer"
  and moved to the last table in the batch.
mysql-test/r/func_group_innodb.result:
  Bug #27531: renamed "Using join cache" to "Using join buffer"
  and moved to the last table in the batch.
mysql-test/r/gis.result:
  Bug #27531: renamed "Using join cache" to "Using join buffer"
  and moved to the last table in the batch.
mysql-test/r/greedy_optimizer.result:
  Bug #27531: renamed "Using join cache" to "Using join buffer"
  and moved to the last table in the batch.
mysql-test/r/group_by.result:
  Bug #27531: renamed "Using join cache" to "Using join buffer"
  and moved to the last table in the batch.
mysql-test/r/group_min_max.result:
  Bug #27531: renamed "Using join cache" to "Using join buffer"
  and moved to the last table in the batch.
mysql-test/r/index_merge_myisam.result:
  Bug #27531: renamed "Using join cache" to "Using join buffer"
  and moved to the last table in the batch.
mysql-test/r/information_schema.result:
  Bug #27531: renamed "Using join cache" to "Using join buffer"
  and moved to the last table in the batch.
mysql-test/r/innodb_gis.result:
  Bug #27531: renamed "Using join cache" to "Using join buffer"
  and moved to the last table in the batch.
mysql-test/r/innodb_mysql.result:
  Bug #27531: renamed "Using join cache" to "Using join buffer"
  and moved to the last table in the batch.
mysql-test/r/join.result:
  Bug #27531: renamed "Using join cache" to "Using join buffer"
  and moved to the last table in the batch.
mysql-test/r/join_nested.result:
  Bug #27531: renamed "Using join cache" to "Using join buffer"
  and moved to the last table in the batch.
mysql-test/r/key_diff.result:
  Bug #27531: renamed "Using join cache" to "Using join buffer"
  and moved to the last table in the batch.
mysql-test/r/myisam.result:
  Bug #27531: renamed "Using join cache" to "Using join buffer"
  and moved to the last table in the batch.
mysql-test/r/ndb_condition_pushdown.result:
  Bug #27531: renamed "Using join cache" to "Using join buffer"
  and moved to the last table in the batch.
mysql-test/r/ndb_gis.result:
  Bug #27531: renamed "Using join cache" to "Using join buffer"
  and moved to the last table in the batch.
mysql-test/r/range.result:
  Bug #27531: renamed "Using join cache" to "Using join buffer"
  and moved to the last table in the batch.
mysql-test/r/row.result:
  Bug #27531: renamed "Using join cache" to "Using join buffer"
  and moved to the last table in the batch.
mysql-test/r/select.result:
  Bug #27531: renamed "Using join cache" to "Using join buffer"
  and moved to the last table in the batch.
mysql-test/r/ssl.result:
  Bug #27531: renamed "Using join cache" to "Using join buffer"
  and moved to the last table in the batch.
mysql-test/r/ssl_compress.result:
  Bug #27531: renamed "Using join cache" to "Using join buffer"
  and moved to the last table in the batch.
mysql-test/r/subselect.result:
  Bug #27531: renamed "Using join cache" to "Using join buffer"
  and moved to the last table in the batch.
mysql-test/r/subselect3.result:
  Bug #27531: renamed "Using join cache" to "Using join buffer"
  and moved to the last table in the batch.
mysql-test/r/union.result:
  Bug #27531: renamed "Using join cache" to "Using join buffer"
  and moved to the last table in the batch.
mysql-test/r/view.result:
  Bug #27531: renamed "Using join cache" to "Using join buffer"
  and moved to the last table in the batch.
sql/sql_select.cc:
  Bug #27531: renamed "Using join cache" to "Using join buffer"
  and moved to the last table in the batch.
2007-05-29 15:58:18 +03:00
unknown
e0d006f348 Merge mysql.com:/d2/hf/mrg/mysql-5.0-opt
into  mysql.com:/d2/hf/mrg/mysql-5.1-opt


mysql-test/r/func_gconcat.result:
  Auto merged
mysql-test/include/mix1.inc:
  Auto merged
mysql-test/r/func_group.result:
  Auto merged
mysql-test/r/innodb_mysql.result:
  Auto merged
mysql-test/t/func_gconcat.test:
  Auto merged
mysql-test/t/func_group.test:
  Auto merged
sql/item.cc:
  Auto merged
sql/item_cmpfunc.cc:
  Auto merged
sql/item_sum.cc:
  Auto merged
sql/sql_select.cc:
  Auto merged
sql/sql_union.cc:
  Auto merged
mysql-test/r/ps.result:
  merging
mysql-test/r/subselect.result:
  merging
mysql-test/r/type_datetime.result:
  SCCS merged
mysql-test/t/ps.test:
  merging
mysql-test/t/subselect.test:
  merging
mysql-test/t/type_datetime.test:
  merging
sql/opt_sum.cc:
  SCCS merged
2007-05-18 20:00:49 +05:00
unknown
418a2983c0 Merge mhansson@bk-internal:/home/bk/mysql-5.0-opt
into  linux-st28.site:/home/martin/mysql/src/5.0o-bug27573


mysql-test/r/func_group.result:
  Auto merged
mysql-test/t/func_group.test:
  bug#27573: hand merged test case
2007-05-16 12:22:20 +03:00
unknown
aaf6acae9b Bug#27573: MIN() on an indexed column which is always NULL sets _other_ results
to NULL

For queries of the form SELECT MIN(key_part_k) FROM t1 
WHERE key_part_1 = const and ... and key_part_k-1 = const,
the opt_sum_query optimization tries to
use an index to substitute MIN/MAX functions with their values according
to the following rules:
1) Insert the minimum non-null values where the WHERE clause still matches, or
3) A row of nulls

However, the correct semantics requires that there is a third case 2)
such that a NULL value is substituted if there are only NULL values for 
key_part_k.

The patch modifies opt_sum_query() to handle this missing case.


mysql-test/r/func_group.result:
  Bug #27573: Correct result
mysql-test/t/func_group.test:
  Bug #27573: test case
sql/opt_sum.cc:
  Bug #27573:
  Added code that will try to read the
  first non-null value for a given complete-field prefix, second
  choice is to read the null, and lastly set the error code if no row
  is found.
2007-05-15 15:29:12 +03:00
unknown
0c835da803 bug #27531: 5.1 part of the fix:
- added join cache indication in EXPLAIN (Extra column).
 - prefer filesort over full scan over 
   index for ORDER BY (because it's faster).
 - when switching from REF to RANGE because
   RANGE uses longer key turn off sort on
   the head table only as the resulting 
   RANGE access is a candidate for join cache
   and we don't want to disable it by sorting
   on the first table only. 


mysql-test/r/archive_gis.result:
  bug #27531: join cache in EXPLAIN
mysql-test/r/compress.result:
  bug #27531:
   - join cache in EXPLAIN. 
   - prefer filesort over full scan over index for ORDER BY.
mysql-test/r/ctype_utf8.result:
  bug #27531: join cache in EXPLAIN
mysql-test/r/derived.result:
  bug #27531: join cache in EXPLAIN
mysql-test/r/distinct.result:
  bug #27531: join cache in EXPLAIN
mysql-test/r/func_group.result:
  bug #27531: join cache in EXPLAIN
mysql-test/r/func_group_innodb.result:
  bug #27531: join cache in EXPLAIN
mysql-test/r/gis.result:
  bug #27531: join cache in EXPLAIN
mysql-test/r/greedy_optimizer.result:
  bug #27531: join cache in EXPLAIN
mysql-test/r/group_by.result:
  bug #27531: join cache in EXPLAIN
mysql-test/r/group_min_max.result:
  bug #27531: join cache in EXPLAIN
mysql-test/r/index_merge_myisam.result:
  bug #27531: join cache in EXPLAIN
mysql-test/r/information_schema.result:
  bug #27531: join cache in EXPLAIN
mysql-test/r/innodb_gis.result:
  bug #27531: join cache in EXPLAIN
mysql-test/r/innodb_mysql.result:
  bug #27531: join cache in EXPLAIN
mysql-test/r/join.result:
  bug #27531: join cache in EXPLAIN
mysql-test/r/join_nested.result:
  bug #27531: join cache in EXPLAIN
mysql-test/r/key_diff.result:
  bug #27531: join cache in EXPLAIN
mysql-test/r/myisam.result:
  bug #27531: join cache in EXPLAIN
mysql-test/r/ndb_condition_pushdown.result:
  bug #27531: join cache in EXPLAIN
mysql-test/r/ndb_gis.result:
  bug #27531: join cache in EXPLAIN
mysql-test/r/range.result:
  bug #27531: join cache in EXPLAIN
mysql-test/r/row.result:
  bug #27531: join cache in EXPLAIN
mysql-test/r/select.result:
  bug #27531:
   - join cache in EXPLAIN.
   - prefer filesort over full scan over index for ORDER BY.
mysql-test/r/ssl.result:
  bug #27531:
   - join cache in EXPLAIN.
   - prefer filesort over full scan over index for ORDER BY.
mysql-test/r/ssl_compress.result:
  bug #27531:
   - join cache in EXPLAIN.
   - prefer filesort over full scan over index for ORDER BY.
mysql-test/r/subselect.result:
  bug #27531: join cache in EXPLAIN
mysql-test/r/subselect3.result:
  bug #27531: join cache in EXPLAIN
mysql-test/r/union.result:
  bug #27531: join cache in EXPLAIN
mysql-test/r/view.result:
  bug #27531: join cache in EXPLAIN
sql/sql_select.cc:
  bug #27531:
   - join cache in EXPLAIN.
   - prefer filesort over full scan over
     index for ORDER BY.
   - disable sorting on the first table only
     when switching from REF to RANGE.
2007-05-04 18:06:06 +03:00
unknown
9683b0ae68 Merge mysql.com:/home/ram/work/mysql-5.0-maint
into  mysql.com:/home/ram/work/b21976/my50-b21976


sql/item.h:
  Auto merged
mysql-test/r/func_group.result:
  merging
mysql-test/t/func_group.test:
  merging
sql/item_sum.cc:
  merging
2007-03-29 13:37:07 +05:00
unknown
66196e5511 Merge mysql.com:/home/ram/work/b21976/my50-b21976
into  mysql.com:/home/ram/work/b21976/my51-b21976


sql/item.h:
  Auto merged
mysql-test/r/func_group.result:
  merging
mysql-test/t/func_group.test:
  merging
sql/item_sum.cc:
  merging
2007-03-29 12:04:02 +05:00
unknown
cded2b70d6 Merge mysql.com:/home/ram/work/b25834/b25834.5.0
into  mysql.com:/home/ram/work/b25834/b25834.5.1


mysql-test/r/func_group.result:
  Auto merged
mysql-test/t/func_group.test:
  Auto merged
2007-02-28 14:37:09 +04:00
unknown
9bbd385a89 Fix for bug #25834: Test failure in "func_group"
Round the results of std() for some calls with double arguments
to avoid double math precision problems.
2007-02-27 11:01:58 +04:00
unknown
e87d593ae1 Merge siva.hindu.god:/usr/home/tim/m/bk/50
into  siva.hindu.god:/usr/home/tim/m/bk/51


BitKeeper/etc/collapsed:
  auto-union
mysql-test/r/func_group.result:
  Auto merged
mysql-test/t/func_group.test:
  Auto merged
sql/item_sum.cc:
  Auto merged
sql/item_sum.h:
  Auto merged
2006-12-26 12:43:57 -07:00
unknown
1fdda68914 In func_group.test, round the results of std() for some calls, because Windows' sqrt() function appears to return fewer "significant" digits than the Unix implementations.
This is for bug #22555.


mysql-test/r/func_group.result:
  Round the results of std() for some calls, because Windows' sqrt() function appears to return fewer "significant" digits than the Unix implementations.
  This is for bug #22555.
mysql-test/t/func_group.test:
  Round the results of std() for some calls, because Windows' sqrt() function appears to return fewer "significant" digits than the Unix implementations.
  This is for bug #22555.
2006-12-26 12:42:54 -07:00
unknown
7e84939ef6 Merge zippy.cornsilk.net:/home/cmiller/work/mysql/bug22555/my51-bug22555
into  zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.1-maint


BitKeeper/etc/collapsed:
  auto-union
sql/item_sum.cc:
  Auto merged
sql/item_sum.h:
  Auto merged
mysql-test/r/func_group.result:
  Manual merge.
mysql-test/t/func_group.test:
  Manual merge.
2006-12-22 16:05:59 -05:00
unknown
01e98327df Merge zippy.cornsilk.net:/home/cmiller/work/mysql/bug22555/my50-bug22555
into  zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.0-maint


BitKeeper/etc/collapsed:
  auto-union
sql/item_sum.cc:
  Auto merged
sql/item_sum.h:
  Auto merged
mysql-test/r/func_group.result:
  Manual merge.
mysql-test/t/func_group.test:
  Manual merge.
2006-12-22 16:02:54 -05:00
unknown
4dcf4cb981 Merge zippy.cornsilk.net:/home/cmiller/work/mysql/bug22555/my50-bug22555
into  zippy.cornsilk.net:/home/cmiller/work/mysql/bug22555/my51-bug22555


BitKeeper/etc/collapsed:
  auto-union
mysql-test/r/func_group.result:
  Auto merged
mysql-test/t/func_group.test:
  Auto merged
sql/item_sum.h:
  Auto merged
sql/item_sum.cc:
  Manual merge.
2006-12-22 15:59:10 -05:00
unknown
82bd9b6b61 Bug#22555: STDDEV yields positive result for groups with only one row
When only one row was present, the subtraction of nearly the same number 
resulted in catastropic cancellation, introducing an error in the 
VARIANCE calculation near 1e-15.  That was sqrt()ed to get STDDEV, the 
error was escallated to near 1e-8.  

The simple fix of testing for a row count of 1 and forcing that to yield 
0.0 is insufficient, as two rows of the same value should also have a
variance of 0.0, yet the error would be about the same.

So, this patch changes the formula that computes the VARIANCE to be one
that is not subject to catastrophic cancellation.

In addition, it now uses only (faster-than-decimal) floating point numbers
to calculate, and renders that to other types on demand.


mysql-test/r/func_group.result:
  Test that the bug is fixed, and that no unexpected behavior arises from the 
  changes.
mysql-test/t/func_group.test:
  Test that the bug is fixed, and that no unexpected behavior arises from the 
  changes.
sql/item_sum.cc:
  Serg's suggestion: Force all VARIANCE calculations to be done with floating-
  point types.  It's faster, and the SQL standard says we may implement these
  functions any way we want.
  
  Additionally, use a form of variance calculation that is not subject to 
  catastrophic cancellation.   
  http://static.flickr.com/108/311308512_5c4e1c0c3d_b.jpg
sql/item_sum.h:
  Remove unused members and add a comment describing the recurrence relation.
2006-12-22 15:37:37 -05:00