mariadb

Tree: 1585368047

Author	SHA1	Message	Date
Sergey Petrunia	5249c0493e	BUG#38072: Wrong result: HAVING not observed in a query with aggregate - Make send_row_on_empty_set() return FALSE when simplify_cond() has found out that HAVING is always FALSE re-committing to put the fix into 5.0 and 5.1	17 years ago
evgen@moonbone.local	21c6145a6e	Bug#27219: Aggregate functions in ORDER BY. Mixing aggregate functions and non-grouping columns is not allowed in the ONLY_FULL_GROUP_BY mode. However in some cases the error wasn't thrown because of insufficient check. In order to check more thoroughly the new algorithm employs a list of outer fields used in a sum function and a SELECT_LEX::full_group_by_flag. Each non-outer field checked to find out whether it's aggregated or not and the current select is marked accordingly. All outer fields that are used under an aggregate function are added to the Item_sum::outer_fields list and later checked by the Item_sum::check_sum_func function.	18 years ago
mhansson/martin@linux-st28.site	199a167246	Bug#31797: error while parsing subqueries -- WHERE is parsed as HAVING The name resolution for correlated subqueries and HAVING clauses failed to distinguish which of two was being performed when there was a reference to an outer aliased field. Fixed by adding the condition that HAVING clause name resulotion is being performed.	18 years ago
kaa@polly.(none)	8c19367881	Fix for bug #32202 : ORDER BY not working with GROUP BY The bug is a regression introduced by the fix for bug30596. The problem was that in cases when groups in GROUP BY correspond to only one row, and there is ORDER BY, the GROUP BY was removed and the ORDER BY rewritten to ORDER BY <group_by_columns> without checking if the columns in GROUP BY and ORDER BY are compatible. This led to incorrect ordering of the result set as it was sorted using the GROUP BY columns. Additionaly, the code discarded ASC/DESC modifiers from ORDER BY even if its columns were compatible with the GROUP BY ones. This patch fixes the regression by checking if ORDER BY columns form a prefix of the GROUP BY ones, and rewriting ORDER BY only in that case, preserving the ASC/DESC modifiers. That check is sufficient, since the GROUP BY columns contain a unique index.	18 years ago
mhansson/martin@linux-st28.site	ab73b25d5b	Bug#30665: Inconsistent optimization of IGNORE INDEX FOR {ORDER BY\|GROUP BY} The optimizer takes different execution paths during EXPLAIN than SELECT, this fix relates only to EXPLAIN, hence no behavior changes. The test of sort keys for ORDER BY was prohibited from considering keys that were mentioned in IGNORE KEYS FOR ORDER BY. This led to two inconsistencies: One was that IGNORE INDEX FOR GROUP BY and IGNORE INDEX FOR ORDER BY gave apparently different EXPLAINs; the latter erroneously claimed to do filesort. The second inconsistency is that the test of sort keys is called twice, finding a sort key the first time but not the second time, leading to the mentioned filesort. Fixed by making the test of sort keys consider all enabled keys on the table. This test rejects keys that are not covering, and for covering keys the hint should be ignored anyway.	18 years ago
gkodinov/kgeorge@magare.gmz	30585c3d2e	Bug #30393 : Test "group_by" fails with a difference in "row count" and strategy (explain) The fix for WL3527 adds tests that test if the index usage hints combinations don't cause syntax errors. The EXPLAIN for one of these tests can be affected by the size of the rowid on the disk (affected by the presence of large file support). Fixed to avoid the platform dependent test result by removing the irrelevant columns from the EXPLAIN result.	19 years ago
mhansson/martin@linux-st28.site	98d34d620c	Bug #30596 GROUP BY optimization gives wrong result order The optimization that uses a unique index to remove GROUP BY did not ensure that the index was actually used, thus violating the ORDER BY that is implied by GROUP BY. Fixed by replacing GROUP BY with ORDER BY if the GROUP BY clause contains a unique index over non-nullable field(s). In case GROUP BY ... ORDER BY null is used, GROUP BY is simply removed.	19 years ago
mhansson/martin@linux-st28.site	a4d5d9204d	Bug #30596 GROUP BY optimization gives wrong result order The optimization that uses a unique index to remove GROUP BY, did not ensure that the index was actually used, thus violating the ORDER BY that is impled by GROUP BY. Fixed by replacing GROUP BY with ORDER BY if the GROUP BY clause contains a unique index. In case GROUP BY ... ORDER BY null is used, GROUP BY is simply removed.	19 years ago
holyfoot/hf@mysql.com/hfmain.(none)	f1ee2d0687	Bug #29717 INSERT INTO SELECT inserts values even if SELECT statement itself returns empty. As a result of this bug 'SELECT AGGREGATE_FUNCTION(fld) ... GROUP BY' can return one row instead of an empty result set. When GROUP BY only has fields of constant tables (with a single row), the optimizer deletes the group_list. After that we lose the information about whether we had an GROUP BY statement. Though it's important as SELECT min(x) from empty_table; and SELECT min(x) from empty_table GROUP BY y; have to return different results - the first query should return one row, second - an empty result set. So here we add the 'group_optimized_away' flag to remember this case when GROUP BY exists in the query and is removed by the optimizer, and check this flag in end_send_group()	19 years ago
mhansson/martin@linux-st28.site	660d647526	Bug#27634: group_by test fails On many architectures, e.g. 68000, x86, the double registers have higher precision than the IEEE standard prescribes. When compiled with flags -O and higher, some double's go into registers and therefore have higher precision. In one test case the cost information of the best and second-best key were close enough to be influenced by this effect, causing a failed test in distribution builds. Fixed by removing some rows from the table in question so that cost information is not influenced by decimals beyond standard definition of double.	19 years ago
evgen@moonbone.local	5cd1f992ce	Bug#27874: Non-grouped columns are allowed by * in ONLY_FULL_GROUP_BY mode. When fields are inserted instead of * in the select list they were not marked for check for the ONLY_FULL_GROUP_BY mode. The Field_iterator_table::create_item() function now marks newly created items for check when in the ONLY_FULL_GROUP_BY mode. The setup_wild() and the insert_fields() functions now maintain the cur_pos_in_select_list counter for the ONLY_FULL_GROUP_BY mode.	19 years ago
gkodinov/kgeorge@magare.gmz	101857299a	WL3527: 5.1 renamed "--old-mode" to "--old" to prevent ambiguity. "old" now appears in SHOW VARIABLES as a read-only option.	19 years ago
gkodinov/kgeorge@macbook.gmz	b9c82eaa89	WL#3527: Extend IGNORE INDEX so places where index is ignored can be specified Currently MySQL allows one to specify what indexes to ignore during join optimization. The scope of the current USE/FORCE/IGNORE INDEX statement is only the FROM clause, while all other clauses are not affected. However, in certain cases, the optimizer may incorrectly choose an index for sorting and/or grouping, and produce an inefficient query plan. This task provides the means to specify what indexes are ignored/used for what operation in a more fine-grained manner, thus making it possible to manually force a better plan. We do this by extending the current IGNORE/USE/FORCE INDEX syntax to: IGNORE/USE/FORCE INDEX [FOR {JOIN \| ORDER \| GROUP BY}] so that: - if no FOR is specified, the index hint will apply everywhere. - if MySQL is started with the compatibility option --old_mode then an index hint without a FOR clause works as in 5.0 (i.e, the index will only be ignored for JOINs, but can still be used to compute ORDER BY). See the WL#3527 for further details.	19 years ago
evgen@moonbone.local	19ee0a94fe	Bug#23417: Too strict checks against GROUP BY in the ONLY_FULL_GROUP_BY mode. Currently in the ONLY_FULL_GROUP_BY mode no hidden fields are allowed in the select list. To ensure this each expression in the select list is checked to be a constant, an aggregate function or to occur in the GROUP BY list. The last two requirements are wrong and doesn't allow valid expressions like "MAX(b) - MIN(b)" or "a + 1" in a query with grouping by a. The correct check implemented by the patch will ensure that: any field reference in the [sub]expressions of the select list is under an aggregate function or is mentioned as member of the group list or is an outer reference or is part of the select list element that coincide with a grouping element. The Item_field objects now can contain the position of the select list expression which they belong to. The position is saved during the field's Item_field::fix_fields() call. The non_agg_fields list for non-aggregated fields is added to the SELECT_LEX class. The SELECT_LEX::cur_pos_in_select_list now contains the position in the select list of the expression being currently fixed.	19 years ago
gkodinov/kgeorge@macbook.gmz	115616381d	BUG#14019 : group by converts literal string to column name When resolving unqualified name references MySQL was not checking what is the item type for the reference. Thus e.g a string literal item that has by convention a name equal to its string value will also work as a reference to a SELECT list item or a table field. Fixed by allowing only Item_ref or Item_field to referenced by (unqualified) name.	19 years ago
gkodinov/kgeorge@macbook.local	13633864bb	Bug #22781 : SQL_BIG_RESULT fails to influence sort plan Currently SQL_BIG_RESULT is checked only at compile time. However, additional optimizations may take place after this check that change the sort method from 'filesort' to sorting via index. As a result the actual plan executed is not the one specified by the SQL_BIG_RESULT hint. Similarly, there is no such test when executing EXPLAIN, resulting in incorrect output. The patch corrects the problem by testing for SQL_BIG_RESULT both during the explain and execution phases.	19 years ago
gkodinov/kgeorge@macbook.gmz	24c5bf6a96	Bug#21174: Index degrades sort performance and optimizer does not honor IGNORE INDEX - fix moved to 5.1	19 years ago
gkodinov/kgeorge@macbook.gmz	903387afc0	Bug #21174 : Index degrades sort performance and optimizer does not honor IGNORE INDEX - reversed the patch for 5.0 and moved to 5.1	19 years ago
gkodinov/kgeorge@macbook.gmz	25eaa521bf	Bug #21174 : Index degrades sort performance and optimizer does not honor IGNORE INDEX - Allow an index to be used for sorting the table instead of filesort only if it is not disabled by IGNORE INDEX.	20 years ago
gkodinov/kgeorge@macbook.mshome.net	0282028292	Bug #20466 : a view is mixing data when there's a trigger on the table When making a place to store field values at the start of each group the real item (not the reference) must be used when deciding which column to copy.	20 years ago
msvensson@neptunus.(none)	e5eb7cbf29	WL#2930 Adding view and cursor 'protocols' to mysqltest - Cleanup of mysqltest.c before extending it	20 years ago
serg@serg.mylan	f16bb5da7e	aftermerge	21 years ago
sergefp@mysql.com	cd813a0911	Post-merge fixes	21 years ago
serg@serg.mylan	a7f2179c29	BUG#12695: Item_func_isnull::update_used_tables did not update const_item_cache	21 years ago
sergefp@mysql.com	e554e61734	Post-merge fixes	21 years ago
evgen@moonbone.local	697836c77f	Fix bug#12266 GROUP BY DATE(LEFT(column,8)) returns result strings with reduced length. When temporary field created for DATE(LEFT(column,8)) expression, max_length value is taken from Item_date_typecast, and it is getting it from underlaid Item_func_left and it's max_length is 8 in given expression. And all this results in stripping last 2 digits. To Item_date_typecast class added its own fix_length_and_dec() function that sets max_length value to 10, which is proper for DATE field.	21 years ago
monty@mysql.com	3c12d0ae54	Added end marker for tests to make future merges easier	21 years ago
monty@mysql.com	5b8683db74	After merge fixes	21 years ago
monty@mysql.com	ec420bfb43	Fixes during review of new code - Mostly indentation fixes - Added missing test - Ensure that Item_func_case() checks for stack overruns - Use real_item() instead of (Item_ref*) item - Fixed wrong error handling	21 years ago
monty@mysql.com	75ff7d8085	After merge fixes Better fix for ON DUPLICATE KEY UPDATE	21 years ago
igor@rurik.mysql.com	be1478f6f9	group_by.result, group_by.test: Added a test case for bug #11414. sql_select.cc: Fixed bug #11414: crash on Windows with some simple GROUP BY queries. It happened to an allocation of an array containing 0 Copy_field elements in setup_copy_fields. The bug had been already fixed in 5.0.	21 years ago
igor@rurik.mysql.com	6a721d03d6	group_by.result, group_by.test: Correction for the test case of bug #11295 to remove warning.	21 years ago
igor@rurik.mysql.com	2104e9e668	group_by.result, group_by.test: Added a test case for bug #11295. item_buff.cc: Fixed bug #11295. This a correction for the patch of bug #11088 that takes into account a possible NULL values of the BLOB column.	21 years ago
igor@rurik.mysql.com	acc6651d24	group_by.result: Added a test case for bug #11385. group_by.test: Added a test case for bug #11385. field.h: Fixed bug #11385. The bug was due to not defined method decimals for the class Field_datetime.	21 years ago
msvensson@neptunus.(none)	6282d89b0a	bug#10466: Datatype "timestamp" displays "YYYYMMDDHHMMSS" irrespective of display sizes. - Print warning that says display width is not supported for datatype TIMESTAMP, if user tries to create a TIMESTAMP column with display width. - Use display width for TIMESTAMP only in type_timestamp test to make sure warning is displayed correctly.	21 years ago
igor@rurik.mysql.com	ad223c9c10	group_by.result, group_by.test: Correction after merge of fix for bug #8614.	21 years ago
igor@rurik.mysql.com	2095758a9d	group_by.result, group_by.test: Added a test case for bug #8614. sql_select.cc: Fixed bug #8614. SELECT DISTINCT ... GROUP BY 'const' must be equivalent to SELECT ... GROUP BY 'const'.	21 years ago
timour@mysql.com	375e79bb6e	Post-fix for BUG#11211 Exclude the query that generates warning from PS tests, due to extra warning under PS.	21 years ago
timour@mysql.com	3220f721dd	Fix for BUG#11211 "GROUP BY doesn't work correctly" When the GROUP BY clause contains a column reference that can be resolved to both an aliased column in the SELECT list, and to a column in the FROM clause, the group column is resolved to the column in the FROM clause (for ANSI conformance). However, it may be so that the user's intent is just the other way around, and he/she gets the query results grouped by a completely different column than expexted. This patch adds a warning in such cases that tells the user that there is potential ambiguity in the group column. sql/sql_select.cc - Added a warning when a GROUP column is ambiguous due to that there is a column reference with the same name both in the SELECT and FROM clauses. In this case we resolve to the column in FROM clause and warn the user of a possible ambiguity. - More extensive comments. - Changed the function to return bool instead of int (as in other places). mysql-test/t/group_by.test Added test for BUG#11211. mysql-test/r/group_by.result Added test for BUG#11211.	21 years ago
igor@rurik.mysql.com	90dd86907e	sql_select.cc, item_buff.cc, item.h: Fixed bug #11088: a crash for queries with GROUP BY a BLOB column + COUNT(DISTINCT...) due to an attempt to allocate a too large buffer for the BLOB field. Now the size of the buffer is limited by max_sort_length. group_by.test, group_by.result: Added a test case for bug #11088.	21 years ago
sergefp@mysql.com	9fbdd4e03f	Fix for BUG#9298: Make int->string conversion sign-aware in Protocol_simple::store_long	21 years ago
sergefp@mysql.com	70e677bd0f	Make the tests deterministic: change DELETE ... LIMIT to DELETE ... ORDER BY ... LIMIT	21 years ago
sergefp@mysql.com	86e3a378ea	Fix for BUG#9213: GROUP BY returns wrong query results: Make test_if_skip_sort_order() rebuild tab->ref if it decides to use an index different from the index join optimizer has choosen.	21 years ago
monty@mysql.com	788a2658a3	Better bug fix for #5569 : "Incorrect "Access Denied" error with SAME login DIFFERENT host" This fixes also the reverse lookup bug introduced by the previous patch	21 years ago
monty@mysql.com	79ec81071a	Better bugfix for "HAVING when refering to RAND()" (Bug #8216 ) Ensure that references in HAVING, ORDER BY or GROUP BY are calculated after fields in SELECT. This will ensure that any reference to these has a valid value. Generalized the code for split_sum_func()	21 years ago
monty@mysql.com	32f91f48e8	Fixed bug in HAVING when refering to RAND() through alias (BUG 8216)	21 years ago
sergefp@mysql.com	f78a60593a	Fix for BUG#6976: In Item_ref::Item_ref set maybe_null (and other fields fix_fields sets) to be the same as in (*ref), because Item_ref::fix_fields() will not be called. Previously maybe_null was 0 always and this produced a bogus state where maybe_null==0 && is_null() == true which broke evaluation for some upper-level Items, like AND and OR.	21 years ago
sergefp@mysql.com	c8422dfcc7	Fix for bug#5400 "GROUP_CONCAT returns everything twice": Don't evaluate the value of GROUP_CONCAT several times for the same 'group', reuse the value instead.	22 years ago
antony@ltantony.rdg.cyberkinetica.homeunix.net	fcf96dbb18	WorkLog#1323 Deprecate the use of TYPE=... Preferred syntax is ENGINE=	22 years ago
konstantin@mysql.com	25a0bfb268	bug #1335 tests followup: --disable_query_log was not a good idea, Serg says	22 years ago

1 2 3

114 Commits (1585368047027e66e6823f9c20d0d8610ae42487)