MySQL 9.1.0
Source Code Documentation
PT_table_value_constructor Class Reference

#include <parse_tree_nodes.h>

Inheritance diagram for PT_table_value_constructor:
[legend]

Public Member Functions

 PT_table_value_constructor (const POS &pos, PT_insert_values_list *row_value_list_arg)
 
bool do_contextualize (Parse_context *pc) override
 
bool has_into_clause () const override
 
bool has_trailing_into_clause () const override
 
bool is_set_operation () const override
 
bool can_absorb_order_and_limit (bool, bool) const override
 True if this query expression can absorb an extraneous order by/limit clause. More...
 
bool is_table_value_constructor () const override
 
PT_insert_values_listget_row_value_list () const override
 
- Public Member Functions inherited from PT_query_expression_body
 PT_query_expression_body (const POS &pos)
 
- Public Member Functions inherited from Parse_tree_node_tmpl< Context >
virtual ~Parse_tree_node_tmpl ()=default
 
bool is_contextualized () const
 
virtual bool contextualize (Context *pc) final
 
void error (Context *pc, const POS &pos) const
 syntax_error() function replacement for deferred reporting of syntax errors More...
 
void error (Context *pc, const POS &pos, const char *msg) const
 syntax_error() function replacement for deferred reporting of syntax errors More...
 
void errorf (Context *pc, const POS &pos, const char *format,...) const
 syntax_error() function replacement for deferred reporting of syntax errors More...
 

Private Types

typedef PT_query_primary super
 

Private Attributes

PT_insert_values_list *const row_value_list
 

Additional Inherited Members

- Public Types inherited from Parse_tree_node_tmpl< Context >
typedef Context context_t
 
- Static Public Member Functions inherited from Parse_tree_node_tmpl< Context >
static void * operator new (size_t size, MEM_ROOT *mem_root, const std::nothrow_t &arg=std::nothrow) noexcept
 
static void operator delete (void *ptr, size_t size)
 
static void operator delete (void *, MEM_ROOT *, const std::nothrow_t &) noexcept
 
- Public Attributes inherited from Parse_tree_node_tmpl< Context >
POS m_pos
 
- Protected Member Functions inherited from PT_query_primary
 PT_query_primary (const POS &pos)
 
- Protected Member Functions inherited from Parse_tree_node_tmpl< Context >
 Parse_tree_node_tmpl ()=delete
 
 Parse_tree_node_tmpl (const POS &pos)
 
 Parse_tree_node_tmpl (const POS &start_pos, const POS &end_pos)
 
bool begin_parse_tree (Show_parse_tree *tree)
 
bool end_parse_tree (Show_parse_tree *tree)
 
virtual bool do_contextualize (Context *pc)
 Do all context-sensitive things and mark the node as contextualized. More...
 
virtual void add_json_info (Json_object *json_obj)
 Add all the node-specific json fields. More...
 

Member Typedef Documentation

◆ super

Constructor & Destructor Documentation

◆ PT_table_value_constructor()

PT_table_value_constructor::PT_table_value_constructor ( const POS pos,
PT_insert_values_list row_value_list_arg 
)
inlineexplicit

Member Function Documentation

◆ can_absorb_order_and_limit()

bool PT_table_value_constructor::can_absorb_order_and_limit ( bool  order,
bool  limit 
) const
inlineoverridevirtual

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.

Parameters
orderTrue if the outer query block has the ORDER BY clause.
limitTrue if the outer query block has the LIMIT clause.

Implements PT_query_expression_body.

◆ do_contextualize()

bool PT_table_value_constructor::do_contextualize ( Parse_context pc)
override

◆ get_row_value_list()

PT_insert_values_list * PT_table_value_constructor::get_row_value_list ( ) const
inlineoverridevirtual

◆ has_into_clause()

bool PT_table_value_constructor::has_into_clause ( ) const
inlineoverridevirtual

◆ has_trailing_into_clause()

bool PT_table_value_constructor::has_trailing_into_clause ( ) const
inlineoverridevirtual

◆ is_set_operation()

bool PT_table_value_constructor::is_set_operation ( ) const
inlineoverridevirtual

◆ is_table_value_constructor()

bool PT_table_value_constructor::is_table_value_constructor ( ) const
inlineoverridevirtual

Member Data Documentation

◆ row_value_list

PT_insert_values_list* const PT_table_value_constructor::row_value_list
private

The documentation for this class was generated from the following files: