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.
when it should use index
Sometimes the LEFT/RIGHT JOIN with an empty table caused an
unnecessary filesort.
Sample query, where t1.i1 is indexed and t3 is empty:
SELECT t1.*, t2.* FROM t1 JOIN t2 ON t1.i1 = t2.i2
LEFT JOIN t3 ON t2.i2 = t3.i3
ORDER BY t1.i1 LIMIT 5;
The server erroneously used an item of empty outer-joined
table as a common constant of a Item_equal (multi-equivalence
expression).
By the fix for the bug 16590 the constant status of such
an item has been propagated to st_table::const_key_parts
map bits related to other Item_equal argument-related
key parts (those are obviously not constant in our case).
As far as test_if_skip_sort_order function skips constant
prefixes of testing keys, this caused an ignorance of
available indices, since some prefixes were marked as
constant by mistake.
mysql-test/r/order_by.result:
Test case for bug #38745.
mysql-test/t/order_by.test:
Test case for bug #38745.
sql/item.h:
Bug #38745: MySQL 5.1 optimizer uses filesort for ORDER BY
when it should use index
Item::is_outer_field() has been added and overloaded for
Item_field and Item_ref classes.
sql/item_cmpfunc.cc:
Bug #38745: MySQL 5.1 optimizer uses filesort for ORDER BY
when it should use index
Item_equal::update_const() and Item_equal::update_used_tables()
have been updated to not take into account the constantness
of outer-joined table items.
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).
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.
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.
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.
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).
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.
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.
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.
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
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.
into bodhi.(none):/opt/local/work/mysql-5.1-runtime
mysql-test/t/mysql.test:
Auto merged
mysql-test/t/mysqltest.test:
Auto merged
mysql-test/t/order_by.test:
Auto merged
mysql-test/t/sp.test:
Auto merged
mysql-test/r/sp.result:
Use local
mysql-test/r/sp.result:
Update results.
mysql-test/t/mysql.test:
Fix a typo.
mysql-test/t/mysqltest.test:
Fix a typo.
mysql-test/t/order_by.test:
Fix a typo.
mysql-test/t/row.test:
Remove an unsupported command.
mysql-test/t/sp.test:
Fix a typo.
mysql-test/t/subselect3.test:
Fix mysqltest warnings - now it warns when sees some suspicious --
comment
into mysql.com:/d2/hf/mrg/mysql-5.1-opt
mysql-test/r/order_by.result:
Auto merged
mysql-test/r/type_set.result:
Auto merged
mysql-test/t/order_by.test:
Auto merged
sql/field.cc:
Auto merged
sql/item_cmpfunc.cc:
Auto merged
sql/item_cmpfunc.h:
Auto merged
sql/sql_select.cc:
Auto merged
sql/sql_table.cc:
Auto merged
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.
into mysql.com:/home/hf/work/mrg/mysql-5.1-opt
mysql-test/r/order_by.result:
Auto merged
mysql-test/r/subselect.result:
Auto merged
mysql-test/t/order_by.test:
Auto merged
mysql-test/t/sp.test:
Auto merged
sql/item.cc:
Auto merged
sql/item_cmpfunc.cc:
Auto merged
sql/item_cmpfunc.h:
Auto merged
sql/item_func.cc:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/sql_base.cc:
Auto merged
sql/sql_insert.cc:
Auto merged
sql/sql_lex.cc:
Auto merged
sql/sql_lex.h:
Auto merged
sql/sql_load.cc:
Auto merged
sql/sql_parse.cc:
Auto merged
sql/sql_select.cc:
Auto merged
sql/sql_update.cc:
Auto merged
mysql-test/r/func_str.result:
merging
mysql-test/r/sp.result:
merging
mysql-test/r/view.result:
merging
mysql-test/t/func_str.test:
merging
mysql-test/t/view.test:
merging
into mysql.com:/home/hf/work/mrg/mysql-5.0-opt
mysql-test/r/order_by.result:
Auto merged
mysql-test/r/subselect.result:
Auto merged
mysql-test/t/order_by.test:
Auto merged
mysql-test/t/sp.test:
Auto merged
sql/item.cc:
Auto merged
sql/item_cmpfunc.cc:
Auto merged
sql/item_cmpfunc.h:
Auto merged
sql/item_func.cc:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/sql_base.cc:
Auto merged
sql/sql_insert.cc:
Auto merged
sql/sql_lex.cc:
Auto merged
sql/sql_lex.h:
Auto merged
sql/sql_load.cc:
Auto merged
sql/sql_parse.cc:
Auto merged
sql/sql_select.cc:
Auto merged
sql/sql_update.cc:
Auto merged
mysql-test/r/func_str.result:
merging
mysql-test/r/sp.result:
merging
mysql-test/r/view.result:
merging
mysql-test/t/func_str.test:
merging
mysql-test/t/view.test:
merging
into mysql.com:/home/hf/work/mrg/mysql-5.1-opt
BUILD/check-cpu:
Auto merged
mysql-test/r/explain.result:
Auto merged
mysql-test/r/func_str.result:
Auto merged
mysql-test/r/func_test.result:
Auto merged
mysql-test/r/subselect.result:
Auto merged
mysql-test/r/update.result:
Auto merged
mysql-test/r/view.result:
Auto merged
mysql-test/t/explain.test:
Auto merged
mysql-test/t/func_str.test:
Auto merged
mysql-test/t/sp.test:
Auto merged
sql/item.cc:
Auto merged
sql/item.h:
Auto merged
sql/item_cmpfunc.cc:
Auto merged
sql/item_func.cc:
Auto merged
sql/item_strfunc.h:
Auto merged
sql/sql_base.cc:
Auto merged
sql/sql_delete.cc:
Auto merged
sql/sql_insert.cc:
Auto merged
sql/sql_lex.cc:
Auto merged
sql/sql_lex.h:
Auto merged
sql/sql_load.cc:
Auto merged
sql/sql_parse.cc:
Auto merged
sql/sql_select.h:
Auto merged
sql/sql_update.cc:
Auto merged
mysql-test/r/func_in.result:
SCCS merged
mysql-test/r/order_by.result:
SCCS merged
mysql-test/r/sp.result:
merging
mysql-test/t/func_in.test:
SCCS merged
mysql-test/t/order_by.test:
SCCS merged
mysql-test/t/view.test:
merging
sql/item_cmpfunc.h:
merging
sql/mysql_priv.h:
merging
sql/sql_select.cc:
SCCS merged
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
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.
into calliope.local.cmiller:/Volumes/Source/src/mysql-5.1-maint
mysql-test/r/order_by.result:
Auto merged
mysql-test/t/order_by.test:
Auto merged
sql/item.cc:
Auto merged
sql/mysql_priv.h:
Auto merged
"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.
into rakia.gmz:/home/kgeorge/mysql/autopush/B16590-5.1-opt
mysql-test/r/order_by.result:
Auto merged
mysql-test/t/order_by.test:
Auto merged
sql/sql_select.cc:
Auto merged
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
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.
into mysql.com:/home/hf/work/mysql-5.0-0mrg
BitKeeper/deleted/.del-mysql_client.test:
Auto merged
include/mysql.h:
Auto merged
libmysqld/lib_sql.cc:
Auto merged
mysql-test/r/order_by.result:
Auto merged
mysql-test/r/query_cache.result:
Auto merged
mysql-test/r/subselect.result:
Auto merged
mysql-test/r/type_newdecimal.result:
Auto merged
mysql-test/t/flush.test:
Auto merged
mysql-test/t/flush_block_commit.test:
Auto merged
mysql-test/t/innodb-deadlock.test:
Auto merged
mysql-test/t/innodb-lock.test:
Auto merged
mysql-test/t/lock_multi.test:
Auto merged
mysql-test/t/mysql.test:
Auto merged
mysql-test/t/query_cache.test:
Auto merged
mysql-test/t/rename.test:
Auto merged
mysql-test/t/show_check.test:
Auto merged
mysql-test/t/status.test:
Auto merged
mysql-test/t/subselect.test:
Auto merged
mysql-test/t/type_newdecimal.test:
Auto merged
sql/field.cc:
Auto merged
sql/field.h:
Auto merged
sql/handler.cc:
Auto merged
sql/item.cc:
Auto merged
sql/item.h:
Auto merged
sql/item_func.cc:
Auto merged
sql/item_func.h:
Auto merged
sql/item_subselect.cc:
Auto merged
sql/item_subselect.h:
Auto merged
sql/item_sum.cc:
Auto merged
sql/item_sum.h:
Auto merged
sql/item_timefunc.cc:
Auto merged
sql/item_timefunc.h:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/protocol.cc:
Auto merged
sql/protocol.h:
Auto merged
sql/sql_base.cc:
Auto merged
sql/sql_class.h:
Auto merged
sql/sql_lex.cc:
Auto merged
sql/sql_lex.h:
Auto merged
sql/sql_parse.cc:
Auto merged
sql/sql_select.cc:
Auto merged
sql/sql_show.cc:
Auto merged
sql/sql_table.cc:
Auto merged
sql/sql_yacc.yy:
Auto merged
sql/table.cc:
Auto merged
sql-common/client.c:
Auto merged
sql-common/my_time.c:
Auto merged
Makefile.am:
merging
client/mysqltest.c:
merging
include/my_time.h:
merging
libmysql/libmysql.c:
merging
mysql-test/t/order_by.test:
merging
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
- 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
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.
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.
