mariadb

Commit Graph

Author	SHA1	Message	Date
Alexander Barkov	caee832df1	MDEV-10124 Incorrect usage of CUBE/ROLLUP and ORDER BY with GROUP_CONCAT(a ORDER BY a) Allowing GROUP_CONCAT(... ORDER BY ..) in queries with ROLLUP. The story of the related code: 1. The original patch from Wax commit: `0b505fb437` date: Tue Mar 18 03:07:40 2003 opt_gorder_clause reused the regular order_clause, which already had some protection against ROLLUP queries: order_clause: ORDER_SYM BY { LEX *lex=Lex; if (lex->current_select->linkage != GLOBAL_OPTIONS_TYPE && lex->current_select->select_lex()->olap != UNSPECIFIED_OLAP_TYPE) { net_printf(lex->thd, ER_WRONG_USAGE, "CUBE/ROLLUP", "ORDER BY"); YYABORT; } } order_list; The assumption that ORDER BY in group_concat() had to have the same ROLLUP restriction (with order_clause) was wrong. Moreover, GROUP_CONCAT() in select_item_list was not affected by this restriction, because WITH ROLLUP goes after select_item_list and therefore sel->olap is always equal to UNSPECIFIED_OLAP_TYPE during select_item_list. GROUP BY was not affected for two reasons: - it goes before WITH ROLLUP and sel->olap is still UNSPECIFIED_OLAP_TYPE - Aggregate functions like AVG(), GROUP_CONCAT() in GROUP BY are not allowed So only GROUP_CONCAT() in HAVING and ORDER BY clauses were erroneously affected by this restriction. 2. Bug#27848 rollup in union part causes error with order of union commit: `3f6073ae63` Author: unknown <igor@olga.mysql.com> 2007-12-15 01:42:46 The condition in the ROLLUP protection code became more complex. Note, opt_gconcat_order still reused the regular order_clause. 3. Bug#16347426 ASSERTION FAILED: (SELECT_INSERT && !TABLES->NEXT_NAME_RESOLUTION_TABLE) \|\| !TAB commit: `2d83663380` author: Chaithra Gopalareddy <chaithra.gopalareddy@oracle.com> date: 2013-04-14 06:00:49 opt_gorder_clause was refactored not to use order_clause and to collect information directly to select->gorder_list. The ROLLUP protection code was duplicated from order_clause to the new version of opt_gorder_clause.	10 years ago
Oleksandr Byelkin	6c414fcf89	MDEV-5542: GROUP_CONCAT truncate output to 65.536 chars when using DISTINCT or ORDER BY port of mysql fix WL#6098	10 years ago
Sergey Vojtovich	1ad294e064	MDEV-7821 - Server crashes in Item_func_group_concat::fix_fields on 2nd execution of PS GROUP_CONCAT() with ORDER BY column position may crash server on PS reexecution. The problem was that arguments array of GROUP_CONCAT() was adjusted to point to temporary elements (resolved ORDER BY fields) during first execution. This patch expands rev. `08763096cb` to restore original arguments array as well.	10 years ago
Sergei Golubchik	8e7d6652ad	CRLF->LF	11 years ago
Vicențiu Ciorbaru	eb47b226d2	MDEV-7820 Server crashes in in my_strcasecmp_utf8 on subquery in ORDER BY clause of GROUP_CONCAT It is possible for Item_field to have a NULL field_name. This is true if the Item_field is created based on a field in a temporary table that has no name. It is thus necessary to do a null check before attempting a strcmp.	11 years ago
Sergei Golubchik	05aba79e98	MDEV-4447 MariaDB sources should have unix-style line endings everywhere	12 years ago
Sergei Golubchik	8aaacc9102	MDEV-3987 uninitialized read in Item_cond::fix_fields leads to crash: select .. where .. in ( select ... ) change Item_func_group_concat to use max_length according to the expected semantics	13 years ago
Sergei Golubchik	78d9fdb134	non-functional cleanup, clarifying CONVERT_IF_BIGGER_TO_BLOB	13 years ago
MySQL Build Team	00447eadd5	Backport into build-201102032246-5.1.52sp1 > ------------------------------------------------------------ > revno: 3517 > revision-id: sergey.glukhov@oracle.com-20101213103926-okypkn10adeeyns8 > parent: davi.arnaut@oracle.com-20101207150620-s49dstok48oy585o > committer: Sergey Glukhov <sergey.glukhov@oracle.com> > branch nick: mysql-5.1-bugteam > timestamp: Mon 2010-12-13 13:39:26 +0300 > message: > Bug#58396 group_concat and explain extended are still crashy > Explain fails at fix_fields stage and some items are left unfixed, > particulary Item_group_concat. Item_group_concat::orig_args field > is uninitialized in this case and Item_group_concat::print call > leads to crash. > The fix: > move the initialization of Item_group_concat::orig_args > into constructor.	15 years ago
MySQL Build Team	1cdbb17732	Backport into build-201102032246-5.1.52sp1 > ------------------------------------------------------------ > revno: 3517 > revision-id: sergey.glukhov@oracle.com-20101213103926-okypkn10adeeyns8 > parent: davi.arnaut@oracle.com-20101207150620-s49dstok48oy585o > committer: Sergey Glukhov <sergey.glukhov@oracle.com> > branch nick: mysql-5.1-bugteam > timestamp: Mon 2010-12-13 13:39:26 +0300 > message: > Bug#58396 group_concat and explain extended are still crashy > Explain fails at fix_fields stage and some items are left unfixed, > particulary Item_group_concat. Item_group_concat::orig_args field > is uninitialized in this case and Item_group_concat::print call > leads to crash. > The fix: > move the initialization of Item_group_concat::orig_args > into constructor.	15 years ago
Gleb Shchepa	086130e3c0	backport of bug #54476 fix from 5.1-bugteam to 5.0-bugteam. Original revid: alexey.kopytov@sun.com-20100723115254-jjwmhq97b9wl932l > Bug #54476: crash when group_concat and 'with rollup' in > prepared statements > > Using GROUP_CONCAT() together with the WITH ROLLUP modifier > could crash the server. > > The reason was a combination of several facts: > > 1. The Item_func_group_concat class stores pointers to ORDER > objects representing the columns in the ORDER BY clause of > GROUP_CONCAT(). > > 2. find_order_in_list() called from > Item_func_group_concat::setup() modifies the ORDER objects so > that their 'item' member points to the arguments list > allocated in the Item_func_group_concat constructor. > > 3. In some cases (e.g. in JOIN::rollup_make_fields) a copy of > the original Item_func_group_concat object could be created by > using the Item_func_group_concat::Item_func_group_concat(THD > thd, Item_func_group_concat item) copy constructor. The > latter essentially creates a shallow copy of the source > object. Memory for the arguments array is allocated on > thd->mem_root, but the pointers for arguments and ORDER are > copied verbatim. > > What happens in the test case is that when executing the query > for the first time, after a copy of the original > Item_func_group_concat object has been created by > JOIN::rollup_make_fields(), find_order_in_list() is called for > this new object. It then resolves ORDER BY by modifying the > ORDER objects so that they point to elements of the arguments > array which is local to the cloned object. When thd->mem_root > is freed upon completing the execution, pointers in the ORDER > objects become invalid. Those ORDER objects, however, are also > shared with the original Item_func_group_concat object which is > preserved between executions of a prepared statement. So the > first call to find_order_in_list() for the original object on > the second execution tries to dereference an invalid pointer. > > The solution is to create copies of the ORDER objects when > copying Item_func_group_concat to not leave any stale pointers > in other instances with different lifecycles. mysql-test/r/func_gconcat.result: Test case for bug #54476. mysql-test/t/func_gconcat.test: Test case for bug #54476. sql/item_sum.cc: Copy the ORDER objects pointed to by the elements of the 'order' array in the copy constructor of Item_func_group_concat. sql/table.h: Removed the unused 'item_copy' member of the ORDER class.	15 years ago
Gleb Shchepa	01521a0afb	backport of bug #54476 fix from 5.1-bugteam to 5.0-bugteam. Original revid: alexey.kopytov@sun.com-20100723115254-jjwmhq97b9wl932l > Bug #54476: crash when group_concat and 'with rollup' in > prepared statements > > Using GROUP_CONCAT() together with the WITH ROLLUP modifier > could crash the server. > > The reason was a combination of several facts: > > 1. The Item_func_group_concat class stores pointers to ORDER > objects representing the columns in the ORDER BY clause of > GROUP_CONCAT(). > > 2. find_order_in_list() called from > Item_func_group_concat::setup() modifies the ORDER objects so > that their 'item' member points to the arguments list > allocated in the Item_func_group_concat constructor. > > 3. In some cases (e.g. in JOIN::rollup_make_fields) a copy of > the original Item_func_group_concat object could be created by > using the Item_func_group_concat::Item_func_group_concat(THD > thd, Item_func_group_concat item) copy constructor. The > latter essentially creates a shallow copy of the source > object. Memory for the arguments array is allocated on > thd->mem_root, but the pointers for arguments and ORDER are > copied verbatim. > > What happens in the test case is that when executing the query > for the first time, after a copy of the original > Item_func_group_concat object has been created by > JOIN::rollup_make_fields(), find_order_in_list() is called for > this new object. It then resolves ORDER BY by modifying the > ORDER objects so that they point to elements of the arguments > array which is local to the cloned object. When thd->mem_root > is freed upon completing the execution, pointers in the ORDER > objects become invalid. Those ORDER objects, however, are also > shared with the original Item_func_group_concat object which is > preserved between executions of a prepared statement. So the > first call to find_order_in_list() for the original object on > the second execution tries to dereference an invalid pointer. > > The solution is to create copies of the ORDER objects when > copying Item_func_group_concat to not leave any stale pointers > in other instances with different lifecycles.	15 years ago
Sergey Glukhov	6330815a0c	Bug#58396 group_concat and explain extended are still crashy Explain fails at fix_fields stage and some items are left unfixed, particulary Item_group_concat. Item_group_concat::orig_args field is uninitialized in this case and Item_group_concat::print call leads to crash. The fix: move the initialization of Item_group_concat::orig_args into constructor. mysql-test/r/func_gconcat.result: test case mysql-test/t/func_gconcat.test: test case sql/item_sum.cc: move the initialization of Item_group_concat::orig_args into constructor.	15 years ago
Sergey Glukhov	4096f35a39	Bug#58396 group_concat and explain extended are still crashy Explain fails at fix_fields stage and some items are left unfixed, particulary Item_group_concat. Item_group_concat::orig_args field is uninitialized in this case and Item_group_concat::print call leads to crash. The fix: move the initialization of Item_group_concat::orig_args into constructor.	15 years ago
Sergey Glukhov	930cf09ec7	test case fix	15 years ago
Sergey Glukhov	942f71b2e0	test case fix	15 years ago
Sergey Glukhov	c04bf683fe	Bug#57194 group_concat cause crash and/or invalid memory reads with type errors The problem is caused by bug49487 fix and became visible after after bug56679 fix. Items are cleaned up and set to unfixed state after filling derived table. So we can not rely on item::fixed state in Item_func_group_concat::print and we can not use 'args' array as items there may be cleaned up. The fix is always to use orig_args array of items as it always should contain the correct data. mysql-test/r/func_gconcat.result: test case mysql-test/t/func_gconcat.test: test case sql/item_sum.cc: The fix is always to use orig_args array of items.	15 years ago
Sergey Glukhov	3a61843a1f	Bug#57194 group_concat cause crash and/or invalid memory reads with type errors The problem is caused by bug49487 fix and became visible after after bug56679 fix. Items are cleaned up and set to unfixed state after filling derived table. So we can not rely on item::fixed state in Item_func_group_concat::print and we can not use 'args' array as items there may be cleaned up. The fix is always to use orig_args array of items as it always should contain the correct data.	15 years ago
Georgi Kodinov	4747f9a773	addendum to the fix for bug #54476 : fixed a failing test case.	16 years ago
Georgi Kodinov	a394519ef9	addendum to the fix for bug #54476 : fixed a failing test case.	16 years ago
Alexey Kopytov	1837dcfee7	Bug #54476 : crash when group_concat and 'with rollup' in prepared statements Using GROUP_CONCAT() together with the WITH ROLLUP modifier could crash the server. The reason was a combination of several facts: 1. The Item_func_group_concat class stores pointers to ORDER objects representing the columns in the ORDER BY clause of GROUP_CONCAT(). 2. find_order_in_list() called from Item_func_group_concat::setup() modifies the ORDER objects so that their 'item' member points to the arguments list allocated in the Item_func_group_concat constructor. 3. In some cases (e.g. in JOIN::rollup_make_fields) a copy of the original Item_func_group_concat object could be created by using the Item_func_group_concat::Item_func_group_concat(THD thd, Item_func_group_concat item) copy constructor. The latter essentially creates a shallow copy of the source object. Memory for the arguments array is allocated on thd->mem_root, but the pointers for arguments and ORDER are copied verbatim. What happens in the test case is that when executing the query for the first time, after a copy of the original Item_func_group_concat object has been created by JOIN::rollup_make_fields(), find_order_in_list() is called for this new object. It then resolves ORDER BY by modifying the ORDER objects so that they point to elements of the arguments array which is local to the cloned object. When thd->mem_root is freed upon completing the execution, pointers in the ORDER objects become invalid. Those ORDER objects, however, are also shared with the original Item_func_group_concat object which is preserved between executions of a prepared statement. So the first call to find_order_in_list() for the original object on the second execution tries to dereference an invalid pointer. The solution is to create copies of the ORDER objects when copying Item_func_group_concat to not leave any stale pointers in other instances with different lifecycles. mysql-test/r/func_gconcat.result: Test case for bug #54476. mysql-test/t/func_gconcat.test: Test case for bug #54476. sql/item_sum.cc: Copy the ORDER objects pointed to by the elements of the 'order' array in the copy constructor of Item_func_group_concat. sql/table.h: Removed the unused 'item_copy' member of the ORDER class.	16 years ago
Alexey Kopytov	bb3fbba1af	Bug #54476 : crash when group_concat and 'with rollup' in prepared statements Using GROUP_CONCAT() together with the WITH ROLLUP modifier could crash the server. The reason was a combination of several facts: 1. The Item_func_group_concat class stores pointers to ORDER objects representing the columns in the ORDER BY clause of GROUP_CONCAT(). 2. find_order_in_list() called from Item_func_group_concat::setup() modifies the ORDER objects so that their 'item' member points to the arguments list allocated in the Item_func_group_concat constructor. 3. In some cases (e.g. in JOIN::rollup_make_fields) a copy of the original Item_func_group_concat object could be created by using the Item_func_group_concat::Item_func_group_concat(THD thd, Item_func_group_concat item) copy constructor. The latter essentially creates a shallow copy of the source object. Memory for the arguments array is allocated on thd->mem_root, but the pointers for arguments and ORDER are copied verbatim. What happens in the test case is that when executing the query for the first time, after a copy of the original Item_func_group_concat object has been created by JOIN::rollup_make_fields(), find_order_in_list() is called for this new object. It then resolves ORDER BY by modifying the ORDER objects so that they point to elements of the arguments array which is local to the cloned object. When thd->mem_root is freed upon completing the execution, pointers in the ORDER objects become invalid. Those ORDER objects, however, are also shared with the original Item_func_group_concat object which is preserved between executions of a prepared statement. So the first call to find_order_in_list() for the original object on the second execution tries to dereference an invalid pointer. The solution is to create copies of the ORDER objects when copying Item_func_group_concat to not leave any stale pointers in other instances with different lifecycles.	16 years ago
Ramil Kalimullin	55852670cc	Fix for bug#52397: another crash with explain extended and group_concat Problem: EXPLAIN EXTENDED was trying to resolve references to freed temporary table fields for GROUP_CONCAT()'s ORDER BY arguments. Fix: use stored original GROUP_CONCAT()'s arguments in such a case. mysql-test/r/func_gconcat.result: Fix for bug#52397: another crash with explain extended and group_concat - test result. mysql-test/t/func_gconcat.test: Fix for bug#52397: another crash with explain extended and group_concat - test case. sql/item_sum.cc: Fix for bug#52397: another crash with explain extended and group_concat - use "pargs", printing ORDER BY arguments in the Item_func_group_concat::print() instead of "order" to avoid possible reference resolving to (freed) temporary table fields.	16 years ago
Ramil Kalimullin	2cf7456e03	Fix for bug#52397: another crash with explain extended and group_concat Problem: EXPLAIN EXTENDED was trying to resolve references to freed temporary table fields for GROUP_CONCAT()'s ORDER BY arguments. Fix: use stored original GROUP_CONCAT()'s arguments in such a case.	16 years ago
Tatiana A. Nurnberg	1fc1f462b6	Bug#49487: crash with explain extended and group_concat in a derived table When EXPLAIN EXTENDED tries to print column names, it checks whether the referenced table is CONST (in which case, the column's value rather than its name will be printed). If no proper table is reference (i.e. because a derived table was used that has since gone out of scope), this will fail spectacularly. This ports an equivalent of the fix for Bug 43354. mysql-test/r/func_gconcat.result: Show that EXPLAIN EXTENDED on a GROUP_CONCAT() on a derived table no longer crashes the server. mysql-test/t/func_gconcat.test: Show that EXPLAIN EXTENDED on a GROUP_CONCAT() on a derived table no longer crashes the server. sql/item_sum.cc: Do not de-ref what cannot be, that is, temp-tables that have gone away. This is of questionable utility anyway, since our deref has the sole purpose of checking whether the table is const (in which case, we'll substitute the column with its value in EXPLAIN EXTENDED - that is all).	16 years ago
Tatiana A. Nurnberg	3678457d3c	Bug#49487: crash with explain extended and group_concat in a derived table When EXPLAIN EXTENDED tries to print column names, it checks whether the referenced table is CONST (in which case, the column's value rather than its name will be printed). If no proper table is reference (i.e. because a derived table was used that has since gone out of scope), this will fail spectacularly. This ports an equivalent of the fix for Bug 43354.	16 years ago
Marc Alff	63e56390a3	WL#2110 (SIGNAL) WL#2265 (RESIGNAL) Manual merge of SIGNAL and RESIGNAL to mysql-trunk-signal, plus required dependencies.	16 years ago
Marc Alff	d5fd452d7c	WL#2110 (SIGNAL) WL#2265 (RESIGNAL) Manual merge of SIGNAL and RESIGNAL to mysql-trunk-signal, plus required dependencies.	16 years ago
unknown	1a68ec2809	Fix for bug #35298 : GROUP_CONCAT with DISTINCT can crash the server The bug is a regression introduced by the patch for bug32798. The code in Item_func_group_concat::clear() relied on the 'distinct' variable to check if 'unique_filter' was initialized. That, however, is not always valid because Item_func_group_concat::setup() can do shortcuts in some cases w/o initializing 'unique_filter'. Fixed by checking the value of 'unique_filter' instead of 'distinct' before dereferencing. mysql-test/r/func_gconcat.result: Added test cases for bugs #35298 and #36024. mysql-test/t/func_gconcat.test: Added test cases for bugs #35298 and #36024. sql/item_sum.cc: Check if unique_filter != NULL before dereferencing it. Non-zero value of distinct does not always mean that unique_filter is initialized because Item_func_group_concat::setup() can do shortcuts is some cases	18 years ago
gkodinov/kgeorge@magare.gmz	e22ef24263	Fix for bug #35298 : GROUP_CONCAT with DISTINCT can crash the server The bug is a regression introduced by the patch for bug32798. The code in Item_func_group_concat::clear() relied on the 'distinct' variable to check if 'unique_filter' was initialized. That, however, is not always valid because Item_func_group_concat::setup() can do shortcuts in some cases w/o initializing 'unique_filter'. Fixed by checking the value of 'unique_filter' instead of 'distinct' before dereferencing.	18 years ago
unknown	f28612eae2	Bug #34747 : crash in debug assertion check after derived table Was a double-free of the Unique member of Item_func_group_concat. This was not causing a crash because the Unique is a descendent of Sql_alloc. Fixed to free the Unique only if it was allocated for the instance of Item_func_group_concat it was referenced from mysql-test/r/func_gconcat.result: Bug #34747: test case mysql-test/t/func_gconcat.test: Bug #34747: test case sql/item_sum.cc: Bug #34747: free the Unique only if it was allocated for this instance of Item_func_group_concat	18 years ago
gkodinov/kgeorge@magare.gmz	0443189d89	Bug #34747 : crash in debug assertion check after derived table Was a double-free of the Unique member of Item_func_group_concat. This was not causing a crash because the Unique is a descendent of Sql_alloc. Fixed to free the Unique only if it was allocated for the instance of Item_func_group_concat it was referenced from	18 years ago
unknown	0c4b3f5784	Bug#32798: DISTINCT in GROUP_CONCAT clause fails when ordering by a column with null values For queries containing GROUP_CONCAT(DISTINCT fields ORDER BY fields), there was a limitation that the DISTINCT fields had to be the same as ORDER BY fields, owing to the fact that one single sorted tree was used for keeping track of tuples, ordering and uniqueness. Fixed by introducing a second structure to handle uniqueness so that the original structure has only to order the result. mysql-test/r/func_gconcat.result: Bug#32798: - Wrong test result turned correct after fix. - Correct test result mysql-test/t/func_gconcat.test: Bug#32798: Test case sql/item_sum.cc: Bug#32798: Implementation of fix. Dead code removal. - removed comment describing this bug - replaced body of function group_concat_key_cmp_with_distinct - removed function group_concat_key_cmp_with_distinct_and_order - Added a Unique object to maintain uniqueness of values. sql/item_sum.h: Bug#32798: Declarations and comments.	18 years ago
mhansson/martin@linux-st28.site	cdeecc5154	Bug#32798: DISTINCT in GROUP_CONCAT clause fails when ordering by a column with null values For queries containing GROUP_CONCAT(DISTINCT fields ORDER BY fields), there was a limitation that the DISTINCT fields had to be the same as ORDER BY fields, owing to the fact that one single sorted tree was used for keeping track of tuples, ordering and uniqueness. Fixed by introducing a second structure to handle uniqueness so that the original structure has only to order the result.	18 years ago
unknown	d5b1d6205b	Bug#30897 GROUP_CONCAT returns extra comma on empty fields The fix is a copy of Martin Friebe's suggestion. added testing for no_appended which will be false if anything, including the empty string is in result mysql-test/r/func_gconcat.result: test result mysql-test/t/func_gconcat.test: test case sql/item_sum.cc: added testing for no_appended which will be False if anything, including the empty string is in result	18 years ago
gluh@mysql.com/eagle.(none)	b943d8cf3c	Bug#30897 GROUP_CONCAT returns extra comma on empty fields The fix is a copy of Martin Friebe's suggestion. added testing for no_appended which will be false if anything, including the empty string is in result	18 years ago
unknown	24a567e9f6	Fix for bug #31154 : field.h:1649: virtual int Field_bit::cmp(const uchar, const uchar): Assertion Problem: GROUP_CONCAT(DISTINCT BIT_FIELD...) uses a tree to store keys; which are constructed using a temporary table fields, see Item_func_group_concat::setup(). As a) we don't store null bits in the tree where the bit fields store parts of their data and b) there's no method to properly compare two table records we've got problem. Fix: convert BIT fields to INT in the temporary table used. mysql-test/r/func_gconcat.result: Fix for bug #31154: field.h:1649: virtual int Field_bit::cmp(const uchar, const uchar): Assertion - test result. mysql-test/t/func_gconcat.test: Fix for bug #31154: field.h:1649: virtual int Field_bit::cmp(const uchar, const uchar): Assertion - test case. sql/item_sum.cc: Fix for bug #31154: field.h:1649: virtual int Field_bit::cmp(const uchar, const uchar): Assertion - force the create_tmp_table() to convert BIT columns to INT in order to be able to compare records containing BIT fields.	18 years ago
ramil/ram@mysql.com/ramil.myoffice.izhnet.ru	84d1e3f8f0	Fix for bug #31154 : field.h:1649: virtual int Field_bit::cmp(const uchar, const uchar): Assertion Problem: GROUP_CONCAT(DISTINCT BIT_FIELD...) uses a tree to store keys; which are constructed using a temporary table fields, see Item_func_group_concat::setup(). As a) we don't store null bits in the tree where the bit fields store parts of their data and b) there's no method to properly compare two table records we've got problem. Fix: convert BIT fields to INT in the temporary table used.	18 years ago
unknown	7f6a816484	Bug#29850: Wrong charset of GROUP_CONCAT result when the select employs a temporary table. The result string of the Item_func_group_concat wasn't initialized in the copying constructor of the Item_func_group_concat class. This led to a wrong charset of GROUP_CONCAT result when the select employs a temporary table. The copying constructor of the Item_func_group_concat class now correctly initializes the charset of the result string. mysql-test/t/func_gconcat.test: Added a test case for the bug#29850: Wrong charset of the GROUP_CONCAT result when the select employs a temporary table. mysql-test/r/func_gconcat.result: Added a test case for the bug#29850: Wrong charset of the GROUP_CONCAT result when the select employs a temporary table. sql/item_sum.cc: Bug#29850: Wrong charset of GROUP_CONCAT result when the select employs a temporary table. The copying constructor of the Item_func_group_concat class now correctly initializes the charset of the result string.	19 years ago
evgen@moonbone.local	934089a82b	Bug#29850: Wrong charset of GROUP_CONCAT result when the select employs a temporary table. The result string of the Item_func_group_concat wasn't initialized in the copying constructor of the Item_func_group_concat class. This led to a wrong charset of GROUP_CONCAT result when the select employs a temporary table. The copying constructor of the Item_func_group_concat class now correctly initializes the charset of the result string.	19 years ago
unknown	84966af9fc	bug#23856	19 years ago
mhansson@dl145s.mysql.com	6530f6806a	bug#23856	19 years ago
unknown	10be360ece	bug#28273: GROUP_CONCAT and ORDER BY: No warning when result gets truncated. When using GROUP_CONCAT with ORDER BY, a tree is used for the sorting, as opposed to normal nested loops join used when there is no ORDER BY. The tree traversal that generates the result counts the lines that have been cut down. (as they get cut down to the field's max_size) But the check of that count was before the tree traversal, so no warning was generated if the output is truncated. Fixed by moving the check to after the tree traversal. mysql-test/r/func_gconcat.result: bug#28273: correct result mysql-test/t/func_gconcat.test: bug#28273: test case sql/item_sum.cc: bug#28273: the fix Moved the code that outputs a warning to after temporary table (tree) is traversed.	19 years ago
mhansson/martin@linux-st28.site	b1375104b3	bug#28273: GROUP_CONCAT and ORDER BY: No warning when result gets truncated. When using GROUP_CONCAT with ORDER BY, a tree is used for the sorting, as opposed to normal nested loops join used when there is no ORDER BY. The tree traversal that generates the result counts the lines that have been cut down. (as they get cut down to the field's max_size) But the check of that count was before the tree traversal, so no warning was generated if the output is truncated. Fixed by moving the check to after the tree traversal.	19 years ago
unknown	40c1a3f9a2	Bug #26815 : When creating a temporary table the concise column type of a string expression is decided based on its length: - if its length is under 512 it is stored as either varchar or char. - otherwise it is stored as a BLOB. There is a flag (convert_blob_length) to create_tmp_field that, when >0 allows to force creation of a varchar if the max blob length is under convert_blob_length. However it must be verified that convert_blob_length (settable through a SQL option in some cases) is under the maximum that can be stored in a varchar column. While performing that check for expressions in create_tmp_field_from_item the max length of the blob was used instead. This causes blob columns to be created in the heap temp table used by GROUP_CONCAT (where blobs must not be created in the temp table because of the constant convert_blob_length that is passed to create_tmp_field() ). And since these blob columns are not expected in that place we get wrong results. Fixed by checking that the value of the flag variable is in the limits that fit into VARCHAR instead of the max length of the blob column. mysql-test/r/func_gconcat.result: Bug #26815: test case mysql-test/t/func_gconcat.test: Bug #26815: test case sql/item_sum.cc: Bug #26815: wrong length was checked sql/sql_select.cc: Bug #26815: wrong length was checked	19 years ago
gkodinov/kgeorge@magare.gmz	c52e8b3e64	Bug #26815 : When creating a temporary table the concise column type of a string expression is decided based on its length: - if its length is under 512 it is stored as either varchar or char. - otherwise it is stored as a BLOB. There is a flag (convert_blob_length) to create_tmp_field that, when >0 allows to force creation of a varchar if the max blob length is under convert_blob_length. However it must be verified that convert_blob_length (settable through a SQL option in some cases) is under the maximum that can be stored in a varchar column. While performing that check for expressions in create_tmp_field_from_item the max length of the blob was used instead. This causes blob columns to be created in the heap temp table used by GROUP_CONCAT (where blobs must not be created in the temp table because of the constant convert_blob_length that is passed to create_tmp_field() ). And since these blob columns are not expected in that place we get wrong results. Fixed by checking that the value of the flag variable is in the limits that fit into VARCHAR instead of the max length of the blob column.	19 years ago
unknown	8aa2d6bf92	Bug #26815 : When creating a temporary table the concise column type of a string expression is decided based on its length: - if its length is under 512 it is stored as either varchar or char. - otherwise it is stored as a BLOB. There is a flag (convert_blob_length) to create_tmp_field that, when >0 allows to force creation of a varchar if the max blob length is under convert_blob_length. However it must be verified that convert_blob_length (settable through a SQL option in some cases) is under the maximum that can be stored in a varchar column. While performing that check for expressions in create_tmp_field_from_item the max length of the blob was used instead. This causes blob columns to be created in the heap temp table used by GROUP_CONCAT (where blobs must not be created in the temp table because of the constant convert_blob_length that is passed to create_tmp_field() ). And since these blob columns are not expected in that place we get wrong results. Fixed by checking that the value of the flag variable is in the limits that fit into VARCHAR instead of the max length of the blob column. mysql-test/r/func_gconcat.result: Bug #26815: test case mysql-test/t/func_gconcat.test: Bug #26815: test case sql/item_sum.cc: Bug #26815: wrong length was checked sql/sql_select.cc: Bug #26815: wrong length was checked	19 years ago
gkodinov/kgeorge@magare.gmz	4f2ec8f3de	Bug #26815 : When creating a temporary table the concise column type of a string expression is decided based on its length: - if its length is under 512 it is stored as either varchar or char. - otherwise it is stored as a BLOB. There is a flag (convert_blob_length) to create_tmp_field that, when >0 allows to force creation of a varchar if the max blob length is under convert_blob_length. However it must be verified that convert_blob_length (settable through a SQL option in some cases) is under the maximum that can be stored in a varchar column. While performing that check for expressions in create_tmp_field_from_item the max length of the blob was used instead. This causes blob columns to be created in the heap temp table used by GROUP_CONCAT (where blobs must not be created in the temp table because of the constant convert_blob_length that is passed to create_tmp_field() ). And since these blob columns are not expected in that place we get wrong results. Fixed by checking that the value of the flag variable is in the limits that fit into VARCHAR instead of the max length of the blob column.	19 years ago
unknown	140c3ee961	func_group.test, func_group.result, func_gconcat.result, func_gconcat.test: merge fix : removed undeterministic warnings mysql-test/r/func_gconcat.result: merge fix : removed undeterministic warnings mysql-test/r/func_group.result: merge fix : removed undeterministic warnings mysql-test/t/func_gconcat.test: merge fix : removed undeterministic warnings mysql-test/t/func_group.test: merge fix : removed undeterministic warnings	19 years ago
gkodinov/kgeorge@macbook.gmz	36e7fbc033	func_group.test, func_group.result, func_gconcat.result, func_gconcat.test: merge fix : removed undeterministic warnings	19 years ago

1 2 3

119 Commits (caee832df14c3cb7fae34eab379ca33a49be6833)