class PT_query_expression_body : public Parse_tree_node {
public:
virtual bool is_union() const = 0;
/**
True if this query expression can absorb an extraneous order by/limit
clause. The `ORDER BY`/`LIMIT` syntax is mostly consistestent, i.e. a
trailing clause may not refer to the tables in the `<query primary>`, with
one glaring exception:
(...( SELECT ... )...) ORDER BY ...
If the nested query expression doesn't contain `ORDER BY`, the statement
is interpreted as if the `ORDER BY` was absorbed by the innermost query
expression, i.e.:
(...( SELECT ... ORDER BY ... )...)
There is no rewriting of the parse tree nor AST happening here, the
transformation is done by the contextualizer (see
PT_query_expression::contextualize_order_and_limit), which interprets the
parse tree, and builds the AST according to this interpretation. This
interpretation is governed by the following rule: An `ORDER BY` can be
absorbed if none the nested query expressions contains an `ORDER BY` *or*
`LIMIT`. The rule is complex, so here are some examples for illustration:
In these cases the `ORDER BY` *is* absorbed:
( SELECT * FROM t1 ) ORDER BY t1.a;
(( SELECT * FROM t1 )) ORDER BY t1.a;
In these cases the ORDER BY is *not* absorbed:
( SELECT * FROM t1 ORDER BY 1 ) ORDER BY t1.a;
(( SELECT * FROM t1 ) ORDER BY 1 ) ORDER BY t1.a;
( SELECT * FROM t1 LIMIT 1 ) ORDER BY t1.a;
(( SELECT * FROM t1 ) LIMIT 1 ) ORDER BY t1.a;
The same happens with `LIMIT`, obviously, but the optimizer is freeer to
choose when to apply the limit, and there are name no resolution issues
involved.
@param order True if the outer query block has the ORDER BY clause.
@param limit True if the outer query block has the LIMIT clause.
*/
virtual bool can_absorb_order_and_limit(bool order, bool limit) const = 0;
virtual bool has_into_clause() const = 0;
virtual bool has_trailing_into_clause() const = 0;
virtual bool is_table_value_constructor() const = 0;
virtual PT_insert_values_list *get_row_value_list() const = 0;
};
文章评论