f1fea53c75
A tail (ORDER BY / LIMIT / locking clause) that follows a parenthesized query expression is parsed while the select inside the parentheses is the current one, so everything the tail registers - its window functions, the window specifications they introduce and the units of its subqueries - ends up registered in that inner select. When the parenthesized query expression already has a tail of its own, LEX::add_tail_to_query_expression_body_ext_parens() wraps it into a derived table and attaches the new tail to the wrapping select. The registrations were left behind in the inner select, so the ORDER BY of the wrapping select contained window function items that no select had registered: they never got a Window_funcs_sort, were never computed, and their result field was read unset. The subqueries of the tail kept the inner select as their master and name resolution context. Move these registrations to the wrapping select in the new move_tail_registrations(): - The window functions of the tail are the ones its ORDER BY items contain, looked up with Item::walk() and walk_subquery == FALSE so that a window function belonging to a subquery of the tail is not found and stays registered where it was parsed. Each one takes along the window specification it introduced; "OVER win_name" has none of its own, it is looked up by name at fix_fields() time and never reaches window_specs. - Item::walk() does not descend into a window specification, so the items of a moved specification's PARTITION BY and ORDER BY lists are not re-targeted by Lex_order_limit_lock::set_to() and are pointed at the wrapping select's name resolution context here. - The subquery units of the tail are the ones registered in front of the first unit the inner select had when the tail started to be parsed; the grammar remembers it in a mid-rule action. There is no equivalent of the walk above for them: a unit records neither the clause it came from nor its position in the parsed text. They are excluded from the inner select, re-registered in the wrapping select and their Item_subselect::parent_select is updated. Per-select parse state that is not a registration (n_sum_items, with_sum_func, with_rownum, ftfunc_list, uncacheable, and the select_n_where_fields of the tail's own fields) is deliberately left behind, where it is merely over-counted. Also remove the unreachable !unit check - unit is dereferenced on entry - and fix the indentation of the surrounding block.
Code status:
ci.appveyor.com
MariaDB: The innovative open source database
MariaDB was designed as a drop-in replacement of MySQL(R) with more features, new storage engines, fewer bugs, and better performance.
MariaDB is brought to you by the MariaDB Foundation and the MariaDB Corporation. Please read the CREDITS file for details about the MariaDB Foundation, and who is developing MariaDB.
MariaDB is developed by many of the original developers of MySQL who now work for the MariaDB Corporation, the MariaDB Foundation and by many people in the community.
MySQL, which is the base of MariaDB, is a product and trademark of Oracle Corporation, Inc. For a list of developers and other contributors, see the Credits appendix. You can also run 'SHOW authors' to get a list of active contributors.
A description of the MariaDB project and a manual can be found at:
https://mariadb.com/docs/release-notes
Getting the code, building it and testing it
Refer to the following guide: https://mariadb.org/get-involved/getting-started-for-developers/get-code-build-test/ which outlines how to build the source code correctly and run the MariaDB testing framework, as well as which branch to target for your contributions.
Help
More help is available from the Maria Discuss mailing list https://lists.mariadb.org/postorius/lists/discuss.lists.mariadb.org/ and MariaDB's Zulip instance, https://mariadb.zulipchat.com/
Licensing
MariaDB is specifically available only under version 2 of the GNU General Public License (GPLv2). (I.e. Without the "any later version" clause.) This is inherited from MySQL. Please see the README file in the MySQL distribution for more information.
License information can be found in the COPYING file. Third party license information can be found in the THIRDPARTY file.
Bug Reports
Bug and/or error reports regarding MariaDB should be submitted at: https://jira.mariadb.org
For reporting security vulnerabilities, see our security-policy.
The code for MariaDB, including all revision history, can be found at: https://github.com/MariaDB/server