An error occurred fetching the project authors.
- 02 Apr, 2011 1 commit
-
-
Sergey Petrunya authored
- "Using MRR" is no longer shown with range access. - Instead, both range and BKA accesses will show one of the following: = "Rowid-ordered scan" = "Key-ordered scan" = "Key-ordered Rowid-ordered scan" depending on whether DS-MRR implementation will do scan keys in order, rowids in order, or both. - The patch also introduces a way for other storage engines/MRR implementations to pass information to EXPLAIN output about the properties of employed MRR scans.
-
- 05 Mar, 2011 1 commit
-
-
Sergey Petrunya authored
- put the code that sets HA_NULL_PART bit back - Fix test_if_ref/part_of_refkey() so that = NULL-ability of lookup columns does not prevent the equality from being removed (we now have early/late NULLs filtering which will filter out NULL values) = equality is not removed if it is ref_or_null access, and the value of the lookup column can alternate between the lookup value and NULL.
-
- 27 Jan, 2011 1 commit
-
-
Igor Babaev authored
This was another bug in the patch for bug 698882. The new code from this patch did not ensured that substitutions of fields for best equal fields were performed on all AND-OR levels. As a result substitutions for best fields in some predicates that had been used by the range optimizer were not actually performed while range plans could employ these substitutions. This could lead to inconsistent data structures and ultimately to a crash.
-
- 02 Dec, 2010 1 commit
-
-
Igor Babaev authored
The second (final) patch.
-
- 18 Oct, 2010 1 commit
-
-
Igor Babaev authored
about the employed join algorithms. Refactored constructors of the JOIN_CACHE* classes.
-
- 28 Sep, 2010 1 commit
-
-
Igor Babaev authored
Applied the fix for bug #47217 from the mysql-6.0 codebase. The patch adds not null predicates generated for the left parts of the equality predicates used for ref accesses. This is done for such predicates both in where conditions and on conditions. For the where conditions the not null predicates were generated but in 5.0/5.1 they actually never were used due to some lame merge from 4.1 to 5.0. The fix for bug #47217 made these predicates to be used in the condition pushed to the tables. Yet only this patch generates not null predicates for equality predicated from on conditions of outer joins. This patch introduces a performance regression that can be observed on a test case from null_key.test. The regression will disappear after the fix for bug #57024 from mariadb-5.1 is pulled into mariadb-5.3. The patch contains many changes in the outputs of the EXPLAIN commands since generated not null predicates are considered as parts of the conditions pushed to join tables and may add 'Usingwhere' in some rows of EXPLAINs where there used to be no such comments.
-
- 15 Sep, 2010 1 commit
-
-
Sergey Petrunya authored
- First part of the fix: enable Early NULLs filtering to work when WHERE clause is present
-
- 13 Sep, 2010 1 commit
-
-
Martin Hansson authored
ORDER BY computed col GROUP BY implies ORDER BY in the MySQL dialect of SQL. Therefore, when an index on the first table in the query is used, and that index satisfies ordering according to the GROUP BY clause, the query optimizer estimates the number of tuples that need to be read from this index. If there is a LIMIT clause, table statistics on tables following this 'sort table' are employed. There may be a separate ORDER BY clause however, which mandates reading the whole 'sort table' anyway. But the previous estimate was left untouched. Fixed by removing the estimate from EXPLAIN output if GROUP BY is used in conjunction with an ORDER BY clause that mandates using a temporary table.
-
- 15 Jul, 2010 1 commit
-
-
Sergey Petrunya authored
range plans with identical costs.
-
- 15 Dec, 2009 1 commit
-
-
Sergey Petrunya authored
WL#2474 "Multi Range Read: Change the default MRR implementation to implement new MRR interface" WL#2475 "Batched range read functions for MyISAM/InnoDb" "Index condition pushdown for MyISAM/InnoDB" Igor's fix from sp1r-igor@olga.mysql.com-20080330055902-07614: There could be observed the following problems: 1. EXPLAIN did not mention pushdown conditions from on expressions in the 'extra' column. As a result if a query had no where conditions pushed down to a table, but had on conditions pushed to this table the 'extra' column in the EXPLAIN for the table missed 'using where'. 2. Conditions for ref access were not eliminated from on expressions though such conditions were eliminated from the where condition.
-
- 07 Dec, 2009 1 commit
-
-
Georgi Kodinov authored
Part 2 : There was a special optimization on the ref access method for ORDER BY ... DESC that was set without actually looking on the type of the selected index for ORDER BY. Fixed the SELECT ... ORDER BY .. DESC (it uses a different code path compared to the ASC that has been fixed with the previous fix).
-
- 10 Nov, 2009 1 commit
-
-
Georgi Kodinov authored
values We should re-set the access method functions when changing the access method when switching to another index to avoid sorting. Fixed by doing a little re-engineering : encapsulating all the function assignment into a special function and calling it when flipping the indexes.
-
- 07 Oct, 2009 1 commit
-
-
Georgi Kodinov authored
buffering is used FORCE INDEX FOR ORDER BY now prevents the optimizer from using join buffering. As a result the optimizer can use indexed access on the first table and doesn't need to sort the complete resultset at the end of the statement.
-
- 22 Sep, 2009 1 commit
-
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 3059 [merge] > revision-id: martin.hansson@sun.com-20090810140851-aw5peehzdxi4gjja > parent: iggy@mysql.com-20090806145453-ion37sfdsldwwjrj > parent: martin.hansson@sun.com-20090807115140-7fn6wjx0mrui7zl5 > committer: Martin Hansson <martin.hansson@sun.com> > branch nick: 5.1bt > timestamp: Mon 2009-08-10 16:08:51 +0200 > message: > Merge > ------------------------------------------------------------ > Use --include-merges or -n0 to see merged revisions.
-
- 07 Aug, 2009 1 commit
-
-
Martin Hansson authored
Problem 1: When the 'Using index' optimization is used, the optimizer may still - after cost-based optimization - decide to use another index in order to avoid using a temporary table. But when this happens, the flag to the storage engine to read index only (not table) was still set. Fixed by resetting the flag in the storage engine and TABLE structure in the above scenario, unless the new index allows for the same optimization. Problem 2: When a 'ref' access method was employed by cost-based optimizer, (when the column is non-NULLable), it was assumed that it needed no initialization if 'quick' access methods (since they are based on range scan). When ORDER BY optimization overrides the decision, however, it expects to have this initialized and hence crashes. Fixed in 5.1 (was fixed in 6.0 already) by initializing 'quick' even when there's 'ref' access. mysql-test/r/order_by.result: Bug#46454: Test result. mysql-test/t/order_by.test: Bug#46454: Test case. sql/sql_select.cc: Bug#46454: Problem 1 fixed in make_join_select() Problem 2 fixed in test_if_skip_sort_order() sql/table.h: Bug#46454: Added comment to field.
-
- 16 Oct, 2008 1 commit
-
-
Gleb Shchepa authored
Server crashed during a sort order optimization of a dependent subquery: SELECT (SELECT t1.a FROM t1, t2 WHERE t1.a = t2.b AND t2.a = t3.c ORDER BY t1.a) FROM t3; Bitmap of tables, that the reference to outer table column uses, in addition to the regular table bit has the OUTER_REF_TABLE_BIT bit set. The only_eq_ref_tables function traverses this map bit by bit simultaneously with join->map2table list. Obviously join->map2table never contains an entry for the OUTER_REF_TABLE_BIT pseudo-table, so the server crashed there. The only_eq_ref_tables function has been modified to traverse regular table bits only like the update_depend_map function (resetting of the OUTER_REF_TABLE_BIT there is enough, but resetting of the whole set of PSEUDO_TABLE_BITS is used there for sure). mysql-test/r/order_by.result: Added test case for bug #39844. mysql-test/t/order_by.test: Added test case for bug #39844. sql/sql_select.cc: Bug #39844: Query Crash Mysql Server 5.0.67 The only_eq_ref_tables function has been modified to traverse regular table bits only like the update_depend_map function (resetting of the OUTER_REF_TABLE_BIT there is enough, but resetting of the whole set of PSEUDO_TABLE_BITS is used there for sure).
-
- 23 Apr, 2008 1 commit
-
-
unknown authored
The function test_if_skip_sort_order ignored any covering index used for ref access of a table in a query with ORDER BY if this index was incompatible with the ORDER BY list and there was another covering index compatible with this list. As a result sub-optimal execution plans were chosen for some queries with ORDER BY clause. mysql-test/r/distinct.result: Adjusted results after the fix for bug#35844. mysql-test/r/order_by.result: Added a test case for bug#35844. mysql-test/t/order_by.test: Added a test case for bug#35844.
-
- 27 Mar, 2008 1 commit
-
-
unknown authored
The code for executing indexed ORDER BY was not setting all the internal fields correctly when selecting to execute ORDER BY over and index. Fixed by change the access method to one that will use the quick indexed access if one is selected while selecting indexed ORDER BY. mysql-test/r/order_by.result: Bug #35206: test case mysql-test/t/order_by.test: Bug #35206: test case sql/sql_select.cc: Bug #35206: Change the access method when selecting a quick indexed access.
-
- 08 Feb, 2008 1 commit
-
-
unknown authored
The out of memory error was thrown when the sort buffer size were too small. This led to a user confusion. Now filesort throws the error message about sort buffer being too small. mysql-test/t/order_by.test: Added a test case for the bug#31590: Wrong error message on sort buffer being too small. mysql-test/r/order_by.result: Added a test case for the bug#31590: Wrong error message on sort buffer being too small. sql/filesort.cc: Bug#31590: Wrong error message on sort buffer being too small. Now filesort throws the error message about sort buffer being too small instead of out of memory error.
-
- 28 Sep, 2007 1 commit
-
-
unknown authored
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. mysql-test/r/group_by.result: Bug#30665: Changed test result. The plan gets more efficient here. The output is included in order to show that it is still correct. mysql-test/r/order_by.result: Bug#30665: Test result mysql-test/t/group_by.test: Bug#30665: Changed test case to show correctness of changed plan mysql-test/t/order_by.test: Bug#30665: Test case sql/sql_select.cc: Bug#30665: - the fix: Give test_if_skip_sort_order all keys not the subset of non-disabled keys. - Added comment to test_if_skip_sort_order
-
- 05 Aug, 2007 1 commit
-
-
unknown authored
-
- 04 Aug, 2007 1 commit
-
-
unknown authored
-
- 02 Aug, 2007 1 commit
-
-
unknown authored
This patch adds cost estimation for the queries with ORDER BY / GROUP BY and LIMIT. If there was a ref/range access to the table whose rows were required to be ordered in the result set the optimizer always employed this access though a scan by a different index that was compatible with the required order could be cheaper to produce the first L rows of the result set. Now for such queries the optimizer makes a choice between the cheapest ref/range accesses not compatible with the given order and index scans compatible with it. mysql-test/r/distinct.result: Adjusted results for test cases affected fy the fix for bug #28404. mysql-test/r/endspace.result: Adjusted results for test cases affected fy the fix for bug #28404. mysql-test/r/group_by.result: Adjusted results for test cases affected fy the fix for bug #28404. mysql-test/r/group_min_max.result: Adjusted results for test cases affected fy the fix for bug #28404. mysql-test/r/innodb.result: Adjusted results for test cases affected fy the fix for bug #28404. mysql-test/r/innodb_mysql.result: Adjusted results for test cases affected fy the fix for bug #28404. mysql-test/r/merge.result: Adjusted results for test cases affected fy the fix for bug #28404. mysql-test/r/order_by.result: Added a test case for bug #28404. mysql-test/r/select_found.result: Adjusted results for test cases affected fy the fix for bug #28404. mysql-test/r/subselect.result: Adjusted results for test cases affected fy the fix for bug #28404. mysql-test/t/distinct.test: Changed a test case after adding the fix for bug #28404. mysql-test/t/order_by.test: Added a test case for bug #28404. sql/sql_select.cc: Fixed bug#28404. This patch adds cost estimation for the queries with ORDER BY / GROUP BY and LIMIT. Now for such queries the optimizer makes a choice between the cheapest ref/range accesses not compatible with the given order and index scans compatible with it. Modified the function test_if_skip_sort_order to make the above mentioned choice cost based. sql/sql_select.h: Fixed bug#28404. This patch adds cost estimation for the queries with ORDER BY / GROUP BY and LIMIT. Added a new field fot the JOIN_TAB structure.
-
- 04 Apr, 2007 2 commits
- 03 Apr, 2007 1 commit
-
-
unknown authored
IN/BETWEEN predicates in sorting expressions. Wrong results may occur when the select list contains an expression with IN/BETWEEN predicate that differs from a sorting expression by an additional NOT only. Added the method Item_func_opt_neg::eq to compare correctly expressions containing [NOT] IN/BETWEEN. The eq method inherited from the Item_func returns TRUE when comparing 'a IN (1,2)' with 'a NOT IN (1,2)' that is not, of course, correct. mysql-test/r/order_by.result: Added a test case for bug #27532. mysql-test/t/order_by.test: Added a test case for bug #27532. sql/item_cmpfunc.cc: Fixed bug #27532. Added the method Item_func_opt_neg::eq to compare correctly expressions containing [NOT] IN/BETWEEN. The eq method inherited from the Item_func returns TRUE when comparing 'a IN (1,2)' with 'a NOT IN (1,2)' that is not, of course, correct. sql/item_cmpfunc.h: Added the method Item_func_opt_neg::eq to compare correctly expressions containing [NOT] IN/BETWEEN. The eq method inherited from the Item_func returns TRUE when comparing 'a IN (1,2)' with 'a NOT IN (1,2)' that is not, of course, correct.
-
- 07 Mar, 2007 1 commit
-
-
unknown authored
DATE/DATETIME values are out of the currently supported 4 basic value types (INT,STRING,REAL and DECIMAL). So expressions (not fields) of compile type DATE/DATETIME are generally considered as STRING values. This is not so when they are compared : then they are compared as INTEGER values. But the rule for comparison as INTEGERS must be checked explicitly each time when a comparison is to be performed. filesort is one such place. However there the check was not done and hence the expressions (not fields) of type DATE/DATETIME were sorted by their string representation. Fixed to compare them as INTEGER values for filesort. mysql-test/r/order_by.result: Bug #26672: test case mysql-test/t/order_by.test: Bug #26672: test case sql/filesort.cc: Bug #26672: sort dates/times as integers
-
- 06 Mar, 2007 1 commit
-
-
unknown authored
Functions over sum functions wasn't set up correctly for the ORDER BY clause which leads to a wrong order of the result set. The split_sum_func() function is called now for each ORDER BY item that contains a sum function to set it up correctly. mysql-test/t/order_by.test: Added a test case for bug#25376: Incomplete setup of ORDER BY clause results in a wrong result. mysql-test/r/order_by.result: Added a test case for bug#25376: Incomplete setup of ORDER BY clause results in a wrong result. sql/sql_select.cc: Bug#25376: Incomplete setup of ORDER BY clause results in a wrong result. The split_sum_func() function is called now for each ORDER BY item that contains a sum function to set it up correctly.
-
- 09 Feb, 2007 1 commit
-
-
unknown authored
"update existingtable set anycolumn=nonexisting order by nonexisting" would crash the server. Though we would find the reference to a field, that doesn't mean we can then use it to set some values. It could be a reference to another field. If it is NULL, don't try to use it to set values in the Item_field and instead return an error. Over the previous patch, this signals an error at the location of the error, rather than letting the subsequent deref signal it. mysql-test/r/order_by.result: Verify that all permutations work. mysql-test/t/order_by.test: Verify that all permutations work. sql/item.cc: When the field is NULL, don't dereference it when we set_field(). Instead, raise an error.
-
- 22 Jan, 2007 1 commit
-
-
unknown authored
st_table::const_key_parts member is used in determining if certain key has a prefix that is compared to constant(s) in the query predicates. If there's such prefix the index can be used to get the data from the remaining suffix columns in sorted order. However if a field is compared to another field from a "const" table the const_key_parts is not amended. This makes the optimizer unable to detect that the key can be used for sorting and adds an extra filesort. Fixed by updating const_key_parts after reading in the "const" table. mysql-test/r/order_by.result: BUG#16590: Optimized does not do right "const" table pre-read - test case mysql-test/t/order_by.test: BUG#16590: Optimized does not do right "const" table pre-read - test case sql/sql_select.cc: BUG#16590: Optimized does not do right "const" table pre-read - fill up the const_key_parts structure
-
- 10 Jan, 2007 1 commit
-
-
unknown authored
In the method Item_field::fix_fields we try to resolve the name of the field against the names of the aliases that occur in the select list. This is done by a call of the function find_item_in_list. When this function finds several occurrences of the field name it sends an error message to the error queue and returns 0. Yet the code did not take into account that find_item_in_list could return 0 and tried to dereference the returned value. mysql-test/r/order_by.result: Added a test case for bug #25427. mysql-test/t/order_by.test: Added a test case for bug #25427. sql/item.cc: Fixed bug #25427. In the method Item_field::fix_fields we try to resolve the name of the field against the names of the aliases that occur in the select list. This is done by a call of the function find_item_in_list. When this function finds several occurrences of the field name it sends an error message to the error queue and returns 0. Yet the code did not take into account that find_item_in_list could return 0 and tried to dereference the returned value.
-
- 17 Nov, 2006 1 commit
-
-
unknown authored
-
- 03 Nov, 2006 1 commit
-
-
unknown authored
The parser is allocating Item_field for references by name in ORDER BY expressions. Such expressions however may point not only to Item_field in the select list (or to a table column) but also to an arbitrary Item. This causes Item_field::fix_fields to throw an error about missing column. The fix substitutes Item_field for the reference with an Item_ref when not pointing to Item_field. mysql-test/r/order_by.result: Bug #22457: Column alias in ORDER BY works, but not if in an expression - test case mysql-test/t/order_by.test: Bug #22457: Column alias in ORDER BY works, but not if in an expression - test case sql/item.cc: Bug #22457: Column alias in ORDER BY works, but not if in an expression - transform the Item_field made by the parser into Item_ref if it doesn't point to Item_field and it is in allowed context
-
- 29 Sep, 2006 1 commit
-
-
unknown authored
-
- 15 Aug, 2006 2 commits
-
-
unknown authored
- undeterminstic tests fixed mysql-test/r/order_by.result: Bug #21302: Result not properly sorted when using an ORDER BY on a second table in a join - more undeterminstic tests fixed mysql-test/t/order_by.test: Bug #21302: Result not properly sorted when using an ORDER BY on a second table in a join - more undeterminstic tests fixed
-
unknown authored
on a second table in a join - undeterministic output of the test case removed.
-
- 14 Aug, 2006 1 commit
-
-
unknown authored
table in a join The optimizer removes redundant columns in ORDER BY. It is considering redundant every reference to const table column, e.g b in : create table t1 (a int, b int, primary key(a)); select 1 from t1 order by b where a = 1 But it must not remove references to const table columns if the const table is an outer table because there still can be 2 values : the const value and NULL. e.g.: create table t1 (a int, b int, primary key(a)); select t2.b c from t1 left join t1 t2 on (t1.a = t2.a and t2.a = 5) order by c; mysql-test/r/join_outer.result: Bug #21302: Result not properly sorted when using an ORDER BY on a second table in a join - don't remove columns of const tables in ORDER BY if the const table is an outer table. mysql-test/r/order_by.result: Bug #21302: Result not properly sorted when using an ORDER BY on a second table in a join - test case mysql-test/t/order_by.test: Bug #21302: Result not properly sorted when using an ORDER BY on a second table in a join - test case sql/sql_select.cc: Bug #21302: Result not properly sorted when using an ORDER BY on a second table in a join - don't remove columns of const tables in ORDER BY if the const table is an outer table.
-
- 18 Jul, 2006 1 commit
-
-
unknown authored
When a default of '' was specified for TEXT/BLOB columns, the specification was silently ignored. This is presumably to be nice to applications (or people) who generate their column definitions in a not-very-clever fashion. For clarity, doing this now results in a warning, or an error in strict mode. mysql-test/r/federated.result: Update results mysql-test/r/fulltext_distinct.result: Update results mysql-test/r/fulltext_update.result: Update results mysql-test/r/gis-rtree.result: Update results mysql-test/r/gis.result: Update results mysql-test/r/join_outer.result: Update results mysql-test/r/order_by.result: Update results mysql-test/r/type_blob.result: Add new results mysql-test/r/type_ranges.result: Update results mysql-test/t/type_blob.test: Add new test sql/field.cc: Issue a warning when setting '' as the default on a BLOB/TEXT column, and make it an error in strict mode. Also, clarify comments about when NO_DEFAULT_VALUE_FLAG is set.
-
- 21 Apr, 2006 1 commit
-
-
unknown authored
The bug caused wrong result sets for union constructs of the form (SELECT ... ORDER BY order_list1 [LIMIT n]) ORDER BY order_list2. For such queries order lists were concatenated and limit clause was completely neglected. mysql-test/r/order_by.result: Added a test case for bug #18767. mysql-test/t/order_by.test: Added a test case for bug #18767. sql/sql_lex.h: Fixed bug #18767. Placed the code the created a fake SELECT_LEX into a separate function. sql/sql_parse.cc: Fixed bug #18767. Placed the code the created a fake SELECT_LEX into a separate function. sql/sql_select.cc: Fixed bug #18767. Changed the condition on which a SELECT is treated as part of a UNION. The SELECT in (SELECT ... ORDER BY order_list1 [LIMIT n]) ORDER BY order_list2 now is handled in the same way as the first SELECT in a UNION sequence. sql/sql_union.cc: Fixed bug #18767. Changed the condition at which a SELECT is treated as part of a UNION. The SELECT in (SELECT ... ORDER BY order_list1 [LIMIT n]) ORDER BY order_list2 now is handled in the same way as the first SELECT in a UNION sequence. sql/sql_yacc.yy: Fixed bug #18767. Changed the condition at which a SELECT is treated as part of a UNION. The SELECT in (SELECT ... ORDER BY order_list1 [LIMIT n]) ORDER BY order_list2 now is handled in the same way as the first SELECT in a UNION sequence. In the same way is handled the SELECT in (SELECT ... LIMIT n) ORDER BY order list. Yet if there is neither ORDER BY nor LIMIT in the single-select union construct (SELECT ...) ORDER BY order_list then it is still handled as simple select with an order clause.
-
- 23 Aug, 2005 1 commit
-
-
unknown authored
* Provide backwards compatibility extension to name resolution of coalesced columns. The patch allows such columns to be qualified with a table (and db) name, as it is in 4.1. Based on a patch from Monty. * Adjusted tests accordingly to test both backwards compatible name resolution of qualified columns, and ANSI-style resolution of non-qualified columns. For this, each affected test has two versions - one with qualified columns, and one without. mysql-test/include/ps_query.inc: Put back old tests to test that coalesced columns of natural joins can be qualified. mysql-test/r/bdb.result: Put back old tests to test that coalesced columns of natural joins can be qualified. mysql-test/r/innodb.result: Put back old tests to test that coalesced columns of natural joins can be qualified. mysql-test/r/join.result: Put back old tests to test that coalesced columns of natural joins can be qualified. mysql-test/r/join_nested.result: Put back old tests to test that coalesced columns of natural joins can be qualified. mysql-test/r/join_outer.result: Put back old tests to test that coalesced columns of natural joins can be qualified. mysql-test/r/null_key.result: Put back old tests to test that coalesced columns of natural joins can be qualified. mysql-test/r/order_by.result: Put back old tests to test that coalesced columns of natural joins can be qualified. mysql-test/r/ps_2myisam.result: Put back old tests to test that coalesced columns of natural joins can be qualified. mysql-test/r/ps_3innodb.result: Put back old tests to test that coalesced columns of natural joins can be qualified. mysql-test/r/ps_4heap.result: Put back old tests to test that coalesced columns of natural joins can be qualified. mysql-test/r/ps_5merge.result: Put back old tests to test that coalesced columns of natural joins can be qualified. mysql-test/r/ps_6bdb.result: Put back old tests to test that coalesced columns of natural joins can be qualified. mysql-test/r/ps_7ndb.result: Put back old tests to test that coalesced columns of natural joins can be qualified. mysql-test/r/select.result: Put back old tests to test that coalesced columns of natural joins can be qualified. mysql-test/r/subselect.result: Put back old tests to test that coalesced columns of natural joins can be qualified. mysql-test/r/type_ranges.result: Put back old tests to test that coalesced columns of natural joins can be qualified. mysql-test/t/bdb.test: Put back old tests to test that coalesced columns of natural joins can be qualified. mysql-test/t/innodb.test: Put back old tests to test that coalesced columns of natural joins can be qualified. mysql-test/t/join.test: Put back old tests to test that coalesced columns of natural joins can be qualified. mysql-test/t/join_nested.test: Put back old tests to test that coalesced columns of natural joins can be qualified. mysql-test/t/join_outer.test: Put back old tests to test that coalesced columns of natural joins can be qualified. mysql-test/t/null_key.test: Put back old tests to test that coalesced columns of natural joins can be qualified. mysql-test/t/order_by.test: Put back old tests to test that coalesced columns of natural joins can be qualified. mysql-test/t/select.test: Put back old tests to test that coalesced columns of natural joins can be qualified. mysql-test/t/subselect.test: Put back old tests to test that coalesced columns of natural joins can be qualified. mysql-test/t/type_ranges.test: Put back old tests to test that coalesced columns of natural joins can be qualified. sql/sql_base.cc: * Applied Monty's patch for backwards compatible name resolution of qualified columns. The idea is: - When a column is qualified, search for the column in all tables/views underlying each natural join. In this case natural joins are *not* considered leaves. - If a column is not qualified, then consider natural joins as leaves, thus directly search the result columns of natural joins. * Simplified 'find_field_in_tables()' - unified two similar loops into one. sql/table.cc: - Removed method & members not needed after Monty's patch. sql/table.h: - Removed method & members not needed after Monty's patch. tests/mysql_client_test.c: Put back old tests to test that coalesced columns of natural joins can be qualified.
-