2012-08-14 16:23:34 +02:00
|
|
|
/* Copyright (c) 2009, 2010, Oracle and/or its affiliates. All rights reserved.
|
|
|
|
|
|
|
|
This program is free software; you can redistribute it and/or modify
|
|
|
|
it under the terms of the GNU General Public License as published by
|
|
|
|
the Free Software Foundation; version 2 of the License.
|
|
|
|
|
|
|
|
This program is distributed in the hope that it will be useful,
|
|
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
GNU General Public License for more details.
|
|
|
|
|
|
|
|
You should have received a copy of the GNU General Public License
|
|
|
|
along with this program; if not, write to the Free Software
|
2019-05-11 21:19:05 +02:00
|
|
|
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1335 USA */
|
2012-08-14 16:23:34 +02:00
|
|
|
|
|
|
|
/**
|
|
|
|
@file Representation of an SQL command.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef SQL_CMD_INCLUDED
|
|
|
|
#define SQL_CMD_INCLUDED
|
|
|
|
|
|
|
|
/*
|
|
|
|
When a command is added here, be sure it's also added in mysqld.cc
|
|
|
|
in "struct show_var_st status_vars[]= {" ...
|
|
|
|
|
|
|
|
If the command returns a result set or is not allowed in stored
|
|
|
|
functions or triggers, please also make sure that
|
|
|
|
sp_get_flags_for_command (sp_head.cc) returns proper flags for the
|
|
|
|
added SQLCOM_.
|
|
|
|
*/
|
|
|
|
|
|
|
|
enum enum_sql_command {
|
|
|
|
SQLCOM_SELECT, SQLCOM_CREATE_TABLE, SQLCOM_CREATE_INDEX, SQLCOM_ALTER_TABLE,
|
|
|
|
SQLCOM_UPDATE, SQLCOM_INSERT, SQLCOM_INSERT_SELECT,
|
|
|
|
SQLCOM_DELETE, SQLCOM_TRUNCATE, SQLCOM_DROP_TABLE, SQLCOM_DROP_INDEX,
|
|
|
|
|
|
|
|
SQLCOM_SHOW_DATABASES, SQLCOM_SHOW_TABLES, SQLCOM_SHOW_FIELDS,
|
|
|
|
SQLCOM_SHOW_KEYS, SQLCOM_SHOW_VARIABLES, SQLCOM_SHOW_STATUS,
|
|
|
|
SQLCOM_SHOW_ENGINE_LOGS, SQLCOM_SHOW_ENGINE_STATUS, SQLCOM_SHOW_ENGINE_MUTEX,
|
2020-02-28 18:59:01 +01:00
|
|
|
SQLCOM_SHOW_PROCESSLIST, SQLCOM_SHOW_BINLOG_STAT, SQLCOM_SHOW_SLAVE_STAT,
|
2012-08-14 16:23:34 +02:00
|
|
|
SQLCOM_SHOW_GRANTS, SQLCOM_SHOW_CREATE, SQLCOM_SHOW_CHARSETS,
|
|
|
|
SQLCOM_SHOW_COLLATIONS, SQLCOM_SHOW_CREATE_DB, SQLCOM_SHOW_TABLE_STATUS,
|
|
|
|
SQLCOM_SHOW_TRIGGERS,
|
|
|
|
|
|
|
|
SQLCOM_LOAD,SQLCOM_SET_OPTION,SQLCOM_LOCK_TABLES,SQLCOM_UNLOCK_TABLES,
|
|
|
|
SQLCOM_GRANT,
|
|
|
|
SQLCOM_CHANGE_DB, SQLCOM_CREATE_DB, SQLCOM_DROP_DB, SQLCOM_ALTER_DB,
|
|
|
|
SQLCOM_REPAIR, SQLCOM_REPLACE, SQLCOM_REPLACE_SELECT,
|
|
|
|
SQLCOM_CREATE_FUNCTION, SQLCOM_DROP_FUNCTION,
|
|
|
|
SQLCOM_REVOKE,SQLCOM_OPTIMIZE, SQLCOM_CHECK,
|
|
|
|
SQLCOM_ASSIGN_TO_KEYCACHE, SQLCOM_PRELOAD_KEYS,
|
|
|
|
SQLCOM_FLUSH, SQLCOM_KILL, SQLCOM_ANALYZE,
|
|
|
|
SQLCOM_ROLLBACK, SQLCOM_ROLLBACK_TO_SAVEPOINT,
|
|
|
|
SQLCOM_COMMIT, SQLCOM_SAVEPOINT, SQLCOM_RELEASE_SAVEPOINT,
|
|
|
|
SQLCOM_SLAVE_START, SQLCOM_SLAVE_STOP,
|
|
|
|
SQLCOM_BEGIN, SQLCOM_CHANGE_MASTER,
|
|
|
|
SQLCOM_RENAME_TABLE,
|
|
|
|
SQLCOM_RESET, SQLCOM_PURGE, SQLCOM_PURGE_BEFORE, SQLCOM_SHOW_BINLOGS,
|
|
|
|
SQLCOM_SHOW_OPEN_TABLES,
|
|
|
|
SQLCOM_HA_OPEN, SQLCOM_HA_CLOSE, SQLCOM_HA_READ,
|
|
|
|
SQLCOM_SHOW_SLAVE_HOSTS, SQLCOM_DELETE_MULTI, SQLCOM_UPDATE_MULTI,
|
|
|
|
SQLCOM_SHOW_BINLOG_EVENTS, SQLCOM_DO,
|
|
|
|
SQLCOM_SHOW_WARNS, SQLCOM_EMPTY_QUERY, SQLCOM_SHOW_ERRORS,
|
|
|
|
SQLCOM_SHOW_STORAGE_ENGINES, SQLCOM_SHOW_PRIVILEGES,
|
|
|
|
SQLCOM_HELP, SQLCOM_CREATE_USER, SQLCOM_DROP_USER, SQLCOM_RENAME_USER,
|
|
|
|
SQLCOM_REVOKE_ALL, SQLCOM_CHECKSUM,
|
|
|
|
SQLCOM_CREATE_PROCEDURE, SQLCOM_CREATE_SPFUNCTION, SQLCOM_CALL,
|
|
|
|
SQLCOM_DROP_PROCEDURE, SQLCOM_ALTER_PROCEDURE,SQLCOM_ALTER_FUNCTION,
|
|
|
|
SQLCOM_SHOW_CREATE_PROC, SQLCOM_SHOW_CREATE_FUNC,
|
|
|
|
SQLCOM_SHOW_STATUS_PROC, SQLCOM_SHOW_STATUS_FUNC,
|
|
|
|
SQLCOM_PREPARE, SQLCOM_EXECUTE, SQLCOM_DEALLOCATE_PREPARE,
|
|
|
|
SQLCOM_CREATE_VIEW, SQLCOM_DROP_VIEW,
|
|
|
|
SQLCOM_CREATE_TRIGGER, SQLCOM_DROP_TRIGGER,
|
|
|
|
SQLCOM_XA_START, SQLCOM_XA_END, SQLCOM_XA_PREPARE,
|
|
|
|
SQLCOM_XA_COMMIT, SQLCOM_XA_ROLLBACK, SQLCOM_XA_RECOVER,
|
|
|
|
SQLCOM_SHOW_PROC_CODE, SQLCOM_SHOW_FUNC_CODE,
|
|
|
|
SQLCOM_INSTALL_PLUGIN, SQLCOM_UNINSTALL_PLUGIN,
|
|
|
|
SQLCOM_SHOW_AUTHORS, SQLCOM_BINLOG_BASE64_EVENT,
|
2014-08-25 19:08:01 +02:00
|
|
|
SQLCOM_SHOW_PLUGINS, SQLCOM_SHOW_CONTRIBUTORS,
|
2012-08-14 16:23:34 +02:00
|
|
|
SQLCOM_CREATE_SERVER, SQLCOM_DROP_SERVER, SQLCOM_ALTER_SERVER,
|
|
|
|
SQLCOM_CREATE_EVENT, SQLCOM_ALTER_EVENT, SQLCOM_DROP_EVENT,
|
|
|
|
SQLCOM_SHOW_CREATE_EVENT, SQLCOM_SHOW_EVENTS,
|
|
|
|
SQLCOM_SHOW_CREATE_TRIGGER,
|
|
|
|
SQLCOM_ALTER_DB_UPGRADE,
|
|
|
|
SQLCOM_SHOW_PROFILE, SQLCOM_SHOW_PROFILES,
|
|
|
|
SQLCOM_SIGNAL, SQLCOM_RESIGNAL,
|
|
|
|
SQLCOM_SHOW_RELAYLOG_EVENTS,
|
2013-06-15 17:32:08 +02:00
|
|
|
SQLCOM_GET_DIAGNOSTICS,
|
2012-10-19 20:38:59 +02:00
|
|
|
SQLCOM_SLAVE_ALL_START, SQLCOM_SLAVE_ALL_STOP,
|
2021-12-24 15:27:03 +01:00
|
|
|
SQLCOM_SHOW_EXPLAIN,
|
|
|
|
SQLCOM_SHOW_ANALYZE, SQLCOM_SHUTDOWN,
|
2013-10-29 15:08:44 +01:00
|
|
|
SQLCOM_CREATE_ROLE, SQLCOM_DROP_ROLE, SQLCOM_GRANT_ROLE, SQLCOM_REVOKE_ROLE,
|
2014-08-18 21:36:11 +02:00
|
|
|
SQLCOM_COMPOUND,
|
2014-08-25 19:08:01 +02:00
|
|
|
SQLCOM_SHOW_GENERIC,
|
2016-01-17 16:00:19 +01:00
|
|
|
SQLCOM_ALTER_USER,
|
2016-01-19 13:30:19 +01:00
|
|
|
SQLCOM_SHOW_CREATE_USER,
|
2016-10-08 10:32:52 +02:00
|
|
|
SQLCOM_EXECUTE_IMMEDIATE,
|
MDEV-10139 Support for SEQUENCE objects
Working features:
CREATE OR REPLACE [TEMPORARY] SEQUENCE [IF NOT EXISTS] name
[ INCREMENT [ BY | = ] increment ]
[ MINVALUE [=] minvalue | NO MINVALUE ]
[ MAXVALUE [=] maxvalue | NO MAXVALUE ]
[ START [ WITH | = ] start ] [ CACHE [=] cache ] [ [ NO ] CYCLE ]
ENGINE=xxx COMMENT=".."
SELECT NEXT VALUE FOR sequence_name;
SELECT NEXTVAL(sequence_name);
SELECT PREVIOUS VALUE FOR sequence_name;
SELECT LASTVAL(sequence_name);
SHOW CREATE SEQUENCE sequence_name;
SHOW CREATE TABLE sequence_name;
CREATE TABLE sequence-structure ... SEQUENCE=1
ALTER TABLE sequence RENAME TO sequence2;
RENAME TABLE sequence TO sequence2;
DROP [TEMPORARY] SEQUENCE [IF EXISTS] sequence_names
Missing features
- SETVAL(value,sequence_name), to be used with replication.
- Check replication, including checking that sequence tables are marked
not transactional.
- Check that a commit happens for NEXT VALUE that changes table data (may
already work)
- ALTER SEQUENCE. ANSI SQL version of setval.
- Share identical sequence entries to not add things twice to table list.
- testing insert/delete/update/truncate/load data
- Run and fix Alibaba sequence tests (part of mysql-test/suite/sql_sequence)
- Write documentation for NEXT VALUE / PREVIOUS_VALUE
- NEXTVAL in DEFAULT
- Ensure that NEXTVAL in DEFAULT uses database from base table
- Two NEXTVAL for same row should give same answer.
- Oracle syntax sequence_table.nextval, without any FOR or FROM.
- Sequence tables are treated as 'not read constant tables' by SELECT; Would
be better if we would have a separate list for sequence tables so that
select doesn't know about them, except if refereed to with FROM.
Other things done:
- Improved output for safemalloc backtrack
- frm_type_enum changed to Table_type
- Removed lex->is_view and replaced with lex->table_type. This allows
use to more easy check if item is view, sequence or table.
- Added table flag HA_CAN_TABLES_WITHOUT_ROLLBACK, needed for handlers
that want's to support sequences
- Added handler calls:
- engine_name(), to simplify getting engine name for partition and sequences
- update_first_row(), to be able to do efficient sequence implementations.
- Made binlog_log_row() global to be able to call it from ha_sequence.cc
- Added handler variable: row_already_logged, to be able to flag that the
changed row is already logging to replication log.
- Added CF_DB_CHANGE and CF_SCHEMA_CHANGE flags to simplify
deny_updates_if_read_only_option()
- Added sp_add_cfetch() to avoid new conflicts in sql_yacc.yy
- Moved code for add_table_options() out from sql_show.cc::show_create_table()
- Added String::append_longlong() and used it in sql_show.cc to simplify code.
- Added extra option to dd_frm_type() and ha_table_exists to indicate if
the table is a sequence. Needed by DROP SQUENCE to not drop a table.
2017-03-25 22:36:56 +01:00
|
|
|
SQLCOM_CREATE_SEQUENCE,
|
|
|
|
SQLCOM_DROP_SEQUENCE,
|
2017-05-08 01:44:55 +02:00
|
|
|
SQLCOM_ALTER_SEQUENCE,
|
2017-08-18 21:36:42 +02:00
|
|
|
SQLCOM_CREATE_PACKAGE,
|
|
|
|
SQLCOM_DROP_PACKAGE,
|
|
|
|
SQLCOM_CREATE_PACKAGE_BODY,
|
|
|
|
SQLCOM_DROP_PACKAGE_BODY,
|
|
|
|
SQLCOM_SHOW_CREATE_PACKAGE,
|
|
|
|
SQLCOM_SHOW_CREATE_PACKAGE_BODY,
|
|
|
|
SQLCOM_SHOW_STATUS_PACKAGE,
|
|
|
|
SQLCOM_SHOW_STATUS_PACKAGE_BODY,
|
|
|
|
SQLCOM_SHOW_PACKAGE_BODY_CODE,
|
2019-01-14 14:46:49 +01:00
|
|
|
SQLCOM_BACKUP, SQLCOM_BACKUP_LOCK,
|
2012-08-14 16:23:34 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
When a command is added here, be sure it's also added in mysqld.cc
|
2015-06-19 20:57:39 +02:00
|
|
|
in "struct show_var_st com_status_vars[]= {" ...
|
2012-08-14 16:23:34 +02:00
|
|
|
*/
|
|
|
|
/* This should be the last !!! */
|
|
|
|
SQLCOM_END
|
|
|
|
};
|
|
|
|
|
MDEV-28883 Re-design the upper level of handling UPDATE and DELETE statements
This patch introduces a new way of handling UPDATE and DELETE commands at
the top level after the parsing phase. This new way of processing update
and delete statements can be seen in the implementation of the prepare()
and execute() methods from the new Sql_cmd_dml class. This class derived
from the Sql_cmd class can be considered as an interface class for processing
such commands as SELECT, INSERT, UPDATE, DELETE and other comands
manipulating data in tables.
With this patch processing of update and delete statements after parsing
proceeds by the following schema:
- precheck of the access rights is performed for the used tables
- the used tables are opened
- context analysis phase is performed for the statement
- the used tables are locked
- the statement is optimized and executed
- clean-up is performed for the statement
The implementation of the method Sql_cmd_dml::execute() adheres this schema.
The virtual functions of the class Sql_cmd_dml used for precheck of the
access rights, context analysis, optimization and execution allow to adjust
this schema for processing data manipulation statements of any types.
This schema of processing data manipulation statements is taken from the
current MySQL code. Moreover the definition the class Sql_cmd_dml introduced
in this patch is almost a full replica of such class in the existing MySQL.
However the implementation of the derived classes for update and delete
statements is quite different. This implementation employs the JOIN class
for all kinds of update and delete statements. It allows to perform main
bulk of context analysis actions by the function JOIN::prepare(). This
guarantees that characteristics and properties of the statement tree
discovered for optimization phase when doing context analysis are the same
for single-table and multi-table updates and deletes.
With this patch the following functions are gone:
mysql_prepare_update(), mysql_multi_update_prepare(),
mysql_update(), mysql_multi_update(),
mysql_prepare_delete(), mysql_multi_delete_prepare(), mysql_delete().
The code within these functions have been used as much as possible though.
The functions mysql_test_update() and mysql_test_delete() are also not
needed anymore. The method Sql_cmd_dml::prepare() serves processing
- update/delete statement
- PREPARE stmt FROM "<update/delete statement>"
- EXECUTE stmt when stmt is prepared from update/delete statement.
Approved by Oleksandr Byelkin <sanja@mariadb.com>
2022-06-19 01:28:48 +02:00
|
|
|
struct TABLE_LIST;
|
2019-05-31 13:24:40 +02:00
|
|
|
|
|
|
|
class Storage_engine_name
|
|
|
|
{
|
|
|
|
protected:
|
|
|
|
LEX_CSTRING m_storage_engine_name;
|
|
|
|
public:
|
|
|
|
Storage_engine_name()
|
|
|
|
{
|
|
|
|
m_storage_engine_name.str= NULL;
|
|
|
|
m_storage_engine_name.length= 0;
|
|
|
|
}
|
|
|
|
Storage_engine_name(const LEX_CSTRING &name)
|
|
|
|
:m_storage_engine_name(name)
|
|
|
|
{ }
|
|
|
|
bool resolve_storage_engine_with_error(THD *thd,
|
|
|
|
handlerton **ha,
|
|
|
|
bool tmp_table);
|
2019-06-14 07:36:47 +02:00
|
|
|
bool is_set() { return m_storage_engine_name.str != NULL; }
|
2019-05-31 13:24:40 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
|
MDEV-28883 Re-design the upper level of handling UPDATE and DELETE statements
This patch introduces a new way of handling UPDATE and DELETE commands at
the top level after the parsing phase. This new way of processing update
and delete statements can be seen in the implementation of the prepare()
and execute() methods from the new Sql_cmd_dml class. This class derived
from the Sql_cmd class can be considered as an interface class for processing
such commands as SELECT, INSERT, UPDATE, DELETE and other comands
manipulating data in tables.
With this patch processing of update and delete statements after parsing
proceeds by the following schema:
- precheck of the access rights is performed for the used tables
- the used tables are opened
- context analysis phase is performed for the statement
- the used tables are locked
- the statement is optimized and executed
- clean-up is performed for the statement
The implementation of the method Sql_cmd_dml::execute() adheres this schema.
The virtual functions of the class Sql_cmd_dml used for precheck of the
access rights, context analysis, optimization and execution allow to adjust
this schema for processing data manipulation statements of any types.
This schema of processing data manipulation statements is taken from the
current MySQL code. Moreover the definition the class Sql_cmd_dml introduced
in this patch is almost a full replica of such class in the existing MySQL.
However the implementation of the derived classes for update and delete
statements is quite different. This implementation employs the JOIN class
for all kinds of update and delete statements. It allows to perform main
bulk of context analysis actions by the function JOIN::prepare(). This
guarantees that characteristics and properties of the statement tree
discovered for optimization phase when doing context analysis are the same
for single-table and multi-table updates and deletes.
With this patch the following functions are gone:
mysql_prepare_update(), mysql_multi_update_prepare(),
mysql_update(), mysql_multi_update(),
mysql_prepare_delete(), mysql_multi_delete_prepare(), mysql_delete().
The code within these functions have been used as much as possible though.
The functions mysql_test_update() and mysql_test_delete() are also not
needed anymore. The method Sql_cmd_dml::prepare() serves processing
- update/delete statement
- PREPARE stmt FROM "<update/delete statement>"
- EXECUTE stmt when stmt is prepared from update/delete statement.
Approved by Oleksandr Byelkin <sanja@mariadb.com>
2022-06-19 01:28:48 +02:00
|
|
|
class Prepared_statement;
|
|
|
|
|
2012-08-14 16:23:34 +02:00
|
|
|
/**
|
|
|
|
@class Sql_cmd - Representation of an SQL command.
|
|
|
|
|
|
|
|
This class is an interface between the parser and the runtime.
|
|
|
|
The parser builds the appropriate derived classes of Sql_cmd
|
|
|
|
to represent a SQL statement in the parsed tree.
|
|
|
|
The execute() method in the derived classes of Sql_cmd contain the runtime
|
|
|
|
implementation.
|
|
|
|
Note that this interface is used for SQL statements recently implemented,
|
|
|
|
the code for older statements tend to load the LEX structure with more
|
|
|
|
attributes instead.
|
|
|
|
Implement new statements by sub-classing Sql_cmd, as this improves
|
|
|
|
code modularity (see the 'big switch' in dispatch_command()), and decreases
|
|
|
|
the total size of the LEX structure (therefore saving memory in stored
|
|
|
|
programs).
|
|
|
|
The recommended name of a derived class of Sql_cmd is Sql_cmd_<derived>.
|
|
|
|
|
|
|
|
Notice that the Sql_cmd class should not be confused with the
|
|
|
|
Statement class. Statement is a class that is used to manage an SQL
|
|
|
|
command or a set of SQL commands. When the SQL statement text is
|
|
|
|
analyzed, the parser will create one or more Sql_cmd objects to
|
|
|
|
represent the actual SQL commands.
|
|
|
|
*/
|
|
|
|
class Sql_cmd : public Sql_alloc
|
|
|
|
{
|
|
|
|
private:
|
|
|
|
Sql_cmd(const Sql_cmd &); // No copy constructor wanted
|
|
|
|
void operator=(Sql_cmd &); // No assignment operator wanted
|
|
|
|
|
|
|
|
public:
|
|
|
|
/**
|
|
|
|
@brief Return the command code for this statement
|
|
|
|
*/
|
|
|
|
virtual enum_sql_command sql_command_code() const = 0;
|
|
|
|
|
|
|
|
/**
|
MDEV-28883 Re-design the upper level of handling UPDATE and DELETE statements
This patch introduces a new way of handling UPDATE and DELETE commands at
the top level after the parsing phase. This new way of processing update
and delete statements can be seen in the implementation of the prepare()
and execute() methods from the new Sql_cmd_dml class. This class derived
from the Sql_cmd class can be considered as an interface class for processing
such commands as SELECT, INSERT, UPDATE, DELETE and other comands
manipulating data in tables.
With this patch processing of update and delete statements after parsing
proceeds by the following schema:
- precheck of the access rights is performed for the used tables
- the used tables are opened
- context analysis phase is performed for the statement
- the used tables are locked
- the statement is optimized and executed
- clean-up is performed for the statement
The implementation of the method Sql_cmd_dml::execute() adheres this schema.
The virtual functions of the class Sql_cmd_dml used for precheck of the
access rights, context analysis, optimization and execution allow to adjust
this schema for processing data manipulation statements of any types.
This schema of processing data manipulation statements is taken from the
current MySQL code. Moreover the definition the class Sql_cmd_dml introduced
in this patch is almost a full replica of such class in the existing MySQL.
However the implementation of the derived classes for update and delete
statements is quite different. This implementation employs the JOIN class
for all kinds of update and delete statements. It allows to perform main
bulk of context analysis actions by the function JOIN::prepare(). This
guarantees that characteristics and properties of the statement tree
discovered for optimization phase when doing context analysis are the same
for single-table and multi-table updates and deletes.
With this patch the following functions are gone:
mysql_prepare_update(), mysql_multi_update_prepare(),
mysql_update(), mysql_multi_update(),
mysql_prepare_delete(), mysql_multi_delete_prepare(), mysql_delete().
The code within these functions have been used as much as possible though.
The functions mysql_test_update() and mysql_test_delete() are also not
needed anymore. The method Sql_cmd_dml::prepare() serves processing
- update/delete statement
- PREPARE stmt FROM "<update/delete statement>"
- EXECUTE stmt when stmt is prepared from update/delete statement.
Approved by Oleksandr Byelkin <sanja@mariadb.com>
2022-06-19 01:28:48 +02:00
|
|
|
@brief Check whether the statement has been prepared
|
|
|
|
@returns true if this statement is prepared, false otherwise
|
|
|
|
*/
|
|
|
|
bool is_prepared() const { return m_prepared; }
|
|
|
|
|
|
|
|
/**
|
|
|
|
@brief Prepare this SQL statement
|
|
|
|
@param thd global context the processed statement
|
|
|
|
@returns false if success, true if error
|
|
|
|
*/
|
|
|
|
virtual bool prepare(THD *thd)
|
|
|
|
{
|
|
|
|
/* Default behavior for a statement is to have no preparation code. */
|
|
|
|
DBUG_ASSERT(!is_prepared());
|
|
|
|
set_prepared();
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
@brief Execute this SQL statement
|
|
|
|
@param thd global context the processed statement
|
|
|
|
@returns false if success, true if error
|
2012-08-14 16:23:34 +02:00
|
|
|
*/
|
|
|
|
virtual bool execute(THD *thd) = 0;
|
|
|
|
|
2019-05-31 13:24:40 +02:00
|
|
|
virtual Storage_engine_name *option_storage_engine_name()
|
|
|
|
{
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
MDEV-28883 Re-design the upper level of handling UPDATE and DELETE statements
This patch introduces a new way of handling UPDATE and DELETE commands at
the top level after the parsing phase. This new way of processing update
and delete statements can be seen in the implementation of the prepare()
and execute() methods from the new Sql_cmd_dml class. This class derived
from the Sql_cmd class can be considered as an interface class for processing
such commands as SELECT, INSERT, UPDATE, DELETE and other comands
manipulating data in tables.
With this patch processing of update and delete statements after parsing
proceeds by the following schema:
- precheck of the access rights is performed for the used tables
- the used tables are opened
- context analysis phase is performed for the statement
- the used tables are locked
- the statement is optimized and executed
- clean-up is performed for the statement
The implementation of the method Sql_cmd_dml::execute() adheres this schema.
The virtual functions of the class Sql_cmd_dml used for precheck of the
access rights, context analysis, optimization and execution allow to adjust
this schema for processing data manipulation statements of any types.
This schema of processing data manipulation statements is taken from the
current MySQL code. Moreover the definition the class Sql_cmd_dml introduced
in this patch is almost a full replica of such class in the existing MySQL.
However the implementation of the derived classes for update and delete
statements is quite different. This implementation employs the JOIN class
for all kinds of update and delete statements. It allows to perform main
bulk of context analysis actions by the function JOIN::prepare(). This
guarantees that characteristics and properties of the statement tree
discovered for optimization phase when doing context analysis are the same
for single-table and multi-table updates and deletes.
With this patch the following functions are gone:
mysql_prepare_update(), mysql_multi_update_prepare(),
mysql_update(), mysql_multi_update(),
mysql_prepare_delete(), mysql_multi_delete_prepare(), mysql_delete().
The code within these functions have been used as much as possible though.
The functions mysql_test_update() and mysql_test_delete() are also not
needed anymore. The method Sql_cmd_dml::prepare() serves processing
- update/delete statement
- PREPARE stmt FROM "<update/delete statement>"
- EXECUTE stmt when stmt is prepared from update/delete statement.
Approved by Oleksandr Byelkin <sanja@mariadb.com>
2022-06-19 01:28:48 +02:00
|
|
|
/**
|
|
|
|
@brief Set the owning prepared statement
|
|
|
|
*/
|
|
|
|
void set_owner(Prepared_statement *stmt) { m_owner = stmt; }
|
|
|
|
|
|
|
|
/**
|
|
|
|
@breaf Get the owning prepared statement
|
|
|
|
*/
|
|
|
|
Prepared_statement *get_owner() { return m_owner; }
|
|
|
|
|
|
|
|
/**
|
|
|
|
@brief Check whether this command is a DML statement
|
|
|
|
@return true if SQL command is a DML statement, false otherwise
|
|
|
|
*/
|
|
|
|
virtual bool is_dml() const { return false; }
|
|
|
|
|
|
|
|
/**
|
|
|
|
@brief Unprepare prepared statement for the command
|
|
|
|
@param thd global context of the processed statement
|
|
|
|
|
|
|
|
@notes
|
|
|
|
Temporary function used to "unprepare" a prepared statement after
|
|
|
|
preparation, so that a subsequent execute statement will reprepare it.
|
|
|
|
This is done because UNIT::cleanup() will un-resolve all resolved QBs.
|
|
|
|
*/
|
|
|
|
virtual void unprepare(THD *thd)
|
|
|
|
{
|
|
|
|
DBUG_ASSERT(is_prepared());
|
|
|
|
m_prepared = false;
|
|
|
|
}
|
|
|
|
|
2012-08-14 16:23:34 +02:00
|
|
|
protected:
|
MDEV-28883 Re-design the upper level of handling UPDATE and DELETE statements
This patch introduces a new way of handling UPDATE and DELETE commands at
the top level after the parsing phase. This new way of processing update
and delete statements can be seen in the implementation of the prepare()
and execute() methods from the new Sql_cmd_dml class. This class derived
from the Sql_cmd class can be considered as an interface class for processing
such commands as SELECT, INSERT, UPDATE, DELETE and other comands
manipulating data in tables.
With this patch processing of update and delete statements after parsing
proceeds by the following schema:
- precheck of the access rights is performed for the used tables
- the used tables are opened
- context analysis phase is performed for the statement
- the used tables are locked
- the statement is optimized and executed
- clean-up is performed for the statement
The implementation of the method Sql_cmd_dml::execute() adheres this schema.
The virtual functions of the class Sql_cmd_dml used for precheck of the
access rights, context analysis, optimization and execution allow to adjust
this schema for processing data manipulation statements of any types.
This schema of processing data manipulation statements is taken from the
current MySQL code. Moreover the definition the class Sql_cmd_dml introduced
in this patch is almost a full replica of such class in the existing MySQL.
However the implementation of the derived classes for update and delete
statements is quite different. This implementation employs the JOIN class
for all kinds of update and delete statements. It allows to perform main
bulk of context analysis actions by the function JOIN::prepare(). This
guarantees that characteristics and properties of the statement tree
discovered for optimization phase when doing context analysis are the same
for single-table and multi-table updates and deletes.
With this patch the following functions are gone:
mysql_prepare_update(), mysql_multi_update_prepare(),
mysql_update(), mysql_multi_update(),
mysql_prepare_delete(), mysql_multi_delete_prepare(), mysql_delete().
The code within these functions have been used as much as possible though.
The functions mysql_test_update() and mysql_test_delete() are also not
needed anymore. The method Sql_cmd_dml::prepare() serves processing
- update/delete statement
- PREPARE stmt FROM "<update/delete statement>"
- EXECUTE stmt when stmt is prepared from update/delete statement.
Approved by Oleksandr Byelkin <sanja@mariadb.com>
2022-06-19 01:28:48 +02:00
|
|
|
Sql_cmd() : m_prepared(false), m_owner(nullptr)
|
|
|
|
{}
|
2012-08-14 16:23:34 +02:00
|
|
|
|
|
|
|
virtual ~Sql_cmd()
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
Sql_cmd objects are allocated in thd->mem_root.
|
|
|
|
In MySQL, the C++ destructor is never called, the underlying MEM_ROOT is
|
|
|
|
simply destroyed instead.
|
|
|
|
Do not rely on the destructor for any cleanup.
|
|
|
|
*/
|
MDEV-28883 Re-design the upper level of handling UPDATE and DELETE statements
This patch introduces a new way of handling UPDATE and DELETE commands at
the top level after the parsing phase. This new way of processing update
and delete statements can be seen in the implementation of the prepare()
and execute() methods from the new Sql_cmd_dml class. This class derived
from the Sql_cmd class can be considered as an interface class for processing
such commands as SELECT, INSERT, UPDATE, DELETE and other comands
manipulating data in tables.
With this patch processing of update and delete statements after parsing
proceeds by the following schema:
- precheck of the access rights is performed for the used tables
- the used tables are opened
- context analysis phase is performed for the statement
- the used tables are locked
- the statement is optimized and executed
- clean-up is performed for the statement
The implementation of the method Sql_cmd_dml::execute() adheres this schema.
The virtual functions of the class Sql_cmd_dml used for precheck of the
access rights, context analysis, optimization and execution allow to adjust
this schema for processing data manipulation statements of any types.
This schema of processing data manipulation statements is taken from the
current MySQL code. Moreover the definition the class Sql_cmd_dml introduced
in this patch is almost a full replica of such class in the existing MySQL.
However the implementation of the derived classes for update and delete
statements is quite different. This implementation employs the JOIN class
for all kinds of update and delete statements. It allows to perform main
bulk of context analysis actions by the function JOIN::prepare(). This
guarantees that characteristics and properties of the statement tree
discovered for optimization phase when doing context analysis are the same
for single-table and multi-table updates and deletes.
With this patch the following functions are gone:
mysql_prepare_update(), mysql_multi_update_prepare(),
mysql_update(), mysql_multi_update(),
mysql_prepare_delete(), mysql_multi_delete_prepare(), mysql_delete().
The code within these functions have been used as much as possible though.
The functions mysql_test_update() and mysql_test_delete() are also not
needed anymore. The method Sql_cmd_dml::prepare() serves processing
- update/delete statement
- PREPARE stmt FROM "<update/delete statement>"
- EXECUTE stmt when stmt is prepared from update/delete statement.
Approved by Oleksandr Byelkin <sanja@mariadb.com>
2022-06-19 01:28:48 +02:00
|
|
|
DBUG_ASSERT(false);
|
2012-08-14 16:23:34 +02:00
|
|
|
}
|
MDEV-28883 Re-design the upper level of handling UPDATE and DELETE statements
This patch introduces a new way of handling UPDATE and DELETE commands at
the top level after the parsing phase. This new way of processing update
and delete statements can be seen in the implementation of the prepare()
and execute() methods from the new Sql_cmd_dml class. This class derived
from the Sql_cmd class can be considered as an interface class for processing
such commands as SELECT, INSERT, UPDATE, DELETE and other comands
manipulating data in tables.
With this patch processing of update and delete statements after parsing
proceeds by the following schema:
- precheck of the access rights is performed for the used tables
- the used tables are opened
- context analysis phase is performed for the statement
- the used tables are locked
- the statement is optimized and executed
- clean-up is performed for the statement
The implementation of the method Sql_cmd_dml::execute() adheres this schema.
The virtual functions of the class Sql_cmd_dml used for precheck of the
access rights, context analysis, optimization and execution allow to adjust
this schema for processing data manipulation statements of any types.
This schema of processing data manipulation statements is taken from the
current MySQL code. Moreover the definition the class Sql_cmd_dml introduced
in this patch is almost a full replica of such class in the existing MySQL.
However the implementation of the derived classes for update and delete
statements is quite different. This implementation employs the JOIN class
for all kinds of update and delete statements. It allows to perform main
bulk of context analysis actions by the function JOIN::prepare(). This
guarantees that characteristics and properties of the statement tree
discovered for optimization phase when doing context analysis are the same
for single-table and multi-table updates and deletes.
With this patch the following functions are gone:
mysql_prepare_update(), mysql_multi_update_prepare(),
mysql_update(), mysql_multi_update(),
mysql_prepare_delete(), mysql_multi_delete_prepare(), mysql_delete().
The code within these functions have been used as much as possible though.
The functions mysql_test_update() and mysql_test_delete() are also not
needed anymore. The method Sql_cmd_dml::prepare() serves processing
- update/delete statement
- PREPARE stmt FROM "<update/delete statement>"
- EXECUTE stmt when stmt is prepared from update/delete statement.
Approved by Oleksandr Byelkin <sanja@mariadb.com>
2022-06-19 01:28:48 +02:00
|
|
|
|
|
|
|
/**
|
|
|
|
@brief Set this statement as prepared
|
|
|
|
*/
|
|
|
|
void set_prepared() { m_prepared = true; }
|
|
|
|
|
|
|
|
private:
|
|
|
|
/* True when statement has been prepared */
|
|
|
|
bool m_prepared;
|
|
|
|
/* Owning prepared statement, nullptr if not prepared */
|
|
|
|
Prepared_statement *m_owner;
|
|
|
|
|
2012-08-14 16:23:34 +02:00
|
|
|
};
|
|
|
|
|
MDEV-28883 Re-design the upper level of handling UPDATE and DELETE statements
This patch introduces a new way of handling UPDATE and DELETE commands at
the top level after the parsing phase. This new way of processing update
and delete statements can be seen in the implementation of the prepare()
and execute() methods from the new Sql_cmd_dml class. This class derived
from the Sql_cmd class can be considered as an interface class for processing
such commands as SELECT, INSERT, UPDATE, DELETE and other comands
manipulating data in tables.
With this patch processing of update and delete statements after parsing
proceeds by the following schema:
- precheck of the access rights is performed for the used tables
- the used tables are opened
- context analysis phase is performed for the statement
- the used tables are locked
- the statement is optimized and executed
- clean-up is performed for the statement
The implementation of the method Sql_cmd_dml::execute() adheres this schema.
The virtual functions of the class Sql_cmd_dml used for precheck of the
access rights, context analysis, optimization and execution allow to adjust
this schema for processing data manipulation statements of any types.
This schema of processing data manipulation statements is taken from the
current MySQL code. Moreover the definition the class Sql_cmd_dml introduced
in this patch is almost a full replica of such class in the existing MySQL.
However the implementation of the derived classes for update and delete
statements is quite different. This implementation employs the JOIN class
for all kinds of update and delete statements. It allows to perform main
bulk of context analysis actions by the function JOIN::prepare(). This
guarantees that characteristics and properties of the statement tree
discovered for optimization phase when doing context analysis are the same
for single-table and multi-table updates and deletes.
With this patch the following functions are gone:
mysql_prepare_update(), mysql_multi_update_prepare(),
mysql_update(), mysql_multi_update(),
mysql_prepare_delete(), mysql_multi_delete_prepare(), mysql_delete().
The code within these functions have been used as much as possible though.
The functions mysql_test_update() and mysql_test_delete() are also not
needed anymore. The method Sql_cmd_dml::prepare() serves processing
- update/delete statement
- PREPARE stmt FROM "<update/delete statement>"
- EXECUTE stmt when stmt is prepared from update/delete statement.
Approved by Oleksandr Byelkin <sanja@mariadb.com>
2022-06-19 01:28:48 +02:00
|
|
|
struct LEX;
|
|
|
|
class select_result;
|
|
|
|
class Prelocking_strategy;
|
|
|
|
class DML_prelocking_strategy;
|
|
|
|
class Protocol;
|
|
|
|
|
|
|
|
/**
|
|
|
|
@class Sql_cmd_dml - derivative abstract class used for DML statements
|
|
|
|
|
|
|
|
This class is a class derived from Sql_cmd used when processing such
|
|
|
|
data manipulation commands as SELECT, INSERT, UPDATE, DELETE and others
|
|
|
|
that operate over some tables.
|
|
|
|
After the parser phase all these commands are supposed to be processed
|
|
|
|
by the same schema:
|
|
|
|
- precheck of the access rights is performed for the used tables
|
|
|
|
- the used tables are opened
|
|
|
|
- context analysis phase is performed for the statement
|
|
|
|
- the used tables are locked
|
|
|
|
- the statement is optimized and executed
|
|
|
|
- clean-up is performed for the statement.
|
|
|
|
This schema is reflected in the function Sql_cmd_dml::execute() that
|
|
|
|
uses Sql_cmd_dml::prepare is the statement has not been prepared yet.
|
|
|
|
Precheck of the access right, context analysis are specific for statements
|
|
|
|
of a certain type. That's why the methods implementing this operations are
|
|
|
|
declared as abstract in this class.
|
|
|
|
|
|
|
|
@note
|
|
|
|
Currently this class is used only for UPDATE and DELETE commands.
|
|
|
|
*/
|
|
|
|
class Sql_cmd_dml : public Sql_cmd
|
|
|
|
{
|
|
|
|
public:
|
|
|
|
|
|
|
|
/**
|
|
|
|
@brief Check whether the statement changes the contents of used tables
|
|
|
|
@return true if this is data change statement, false otherwise
|
|
|
|
*/
|
|
|
|
virtual bool is_data_change_stmt() const { return true; }
|
|
|
|
|
|
|
|
/**
|
|
|
|
@brief Perform context analysis of the statement
|
|
|
|
@param thd global context the processed statement
|
|
|
|
@returns false on success, true on error
|
|
|
|
*/
|
|
|
|
virtual bool prepare(THD *thd);
|
|
|
|
|
|
|
|
/**
|
|
|
|
Execute the processed statement once
|
|
|
|
@param thd global context the processed statement
|
|
|
|
@returns false on success, true on error
|
|
|
|
*/
|
|
|
|
virtual bool execute(THD *thd);
|
|
|
|
|
|
|
|
virtual bool is_dml() const { return true; }
|
|
|
|
|
|
|
|
select_result *get_result() { return result; }
|
|
|
|
|
|
|
|
protected:
|
|
|
|
Sql_cmd_dml()
|
|
|
|
: Sql_cmd(), lex(nullptr), result(nullptr),
|
|
|
|
m_empty_query(false)
|
|
|
|
{}
|
|
|
|
|
|
|
|
/**
|
|
|
|
@brief Check whether query is guaranteed to return no data
|
|
|
|
@return true if query is guaranteed to return no data, false otherwise
|
|
|
|
|
|
|
|
@todo Also check this for the following cases:
|
|
|
|
- Empty source for multi-table UPDATE and DELETE.
|
|
|
|
- Check empty query expression for INSERT
|
|
|
|
*/
|
|
|
|
bool is_empty_query() const
|
|
|
|
{
|
|
|
|
DBUG_ASSERT(is_prepared());
|
|
|
|
return m_empty_query;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
@brief Set statement as returning no data
|
|
|
|
*/
|
|
|
|
void set_empty_query() { m_empty_query = true; }
|
|
|
|
|
|
|
|
/**
|
|
|
|
@brief Perform precheck of table privileges for the specific command
|
|
|
|
@param thd global context the processed statement
|
|
|
|
@returns false if success, true if false
|
|
|
|
|
|
|
|
@details
|
|
|
|
Check that user has some relevant privileges for all tables involved in
|
|
|
|
the statement, e.g. SELECT privileges for tables selected from, INSERT
|
|
|
|
privileges for tables inserted into, etc. This function will also populate
|
|
|
|
TABLE_LIST::grant with all privileges the user has for each table, which
|
|
|
|
is later used during checking of column privileges.
|
|
|
|
Note that at preparation time, views are not expanded yet. Privilege
|
|
|
|
checking is thus rudimentary and must be complemented with later calls to
|
|
|
|
SELECT_LEX::check_view_privileges().
|
|
|
|
The reason to call this function at such an early stage is to be able to
|
|
|
|
quickly reject statements for which the user obviously has insufficient
|
|
|
|
privileges.
|
|
|
|
*/
|
|
|
|
virtual bool precheck(THD *thd) = 0;
|
|
|
|
|
|
|
|
/**
|
|
|
|
@brief Perform the command-specific actions of the context analysis
|
|
|
|
@param thd global context the processed statement
|
|
|
|
@returns false if success, true if error
|
|
|
|
|
|
|
|
@note
|
|
|
|
This function is called from prepare()
|
|
|
|
*/
|
|
|
|
virtual bool prepare_inner(THD *thd) = 0;
|
|
|
|
|
|
|
|
/**
|
|
|
|
@brief Perform the command-specific actions of optimization and excution
|
|
|
|
@param thd global context the processed statement
|
|
|
|
@returns false on success, true on error
|
|
|
|
*/
|
|
|
|
virtual bool execute_inner(THD *thd);
|
|
|
|
|
|
|
|
virtual DML_prelocking_strategy *get_dml_prelocking_strategy() = 0;
|
|
|
|
|
|
|
|
uint table_count;
|
|
|
|
|
|
|
|
protected:
|
|
|
|
LEX *lex; /**< Pointer to LEX for this statement */
|
|
|
|
select_result *result; /**< Pointer to object for handling of the result */
|
|
|
|
bool m_empty_query; /**< True if query will produce no rows */
|
|
|
|
};
|
|
|
|
|
|
|
|
|
2019-06-25 11:32:34 +02:00
|
|
|
class Sql_cmd_show_slave_status: public Sql_cmd
|
|
|
|
{
|
|
|
|
protected:
|
|
|
|
bool show_all_slaves_status;
|
|
|
|
public:
|
|
|
|
Sql_cmd_show_slave_status()
|
|
|
|
:show_all_slaves_status(false)
|
|
|
|
{}
|
|
|
|
|
|
|
|
Sql_cmd_show_slave_status(bool status_all)
|
|
|
|
:show_all_slaves_status(status_all)
|
|
|
|
{}
|
|
|
|
|
|
|
|
enum_sql_command sql_command_code() const { return SQLCOM_SHOW_SLAVE_STAT; }
|
|
|
|
|
|
|
|
bool execute(THD *thd);
|
|
|
|
bool is_show_all_slaves_stat() { return show_all_slaves_status; }
|
|
|
|
};
|
|
|
|
|
|
|
|
|
2019-06-14 07:36:47 +02:00
|
|
|
class Sql_cmd_create_table_like: public Sql_cmd,
|
|
|
|
public Storage_engine_name
|
2019-05-31 13:24:40 +02:00
|
|
|
{
|
|
|
|
public:
|
|
|
|
Storage_engine_name *option_storage_engine_name() { return this; }
|
|
|
|
bool execute(THD *thd);
|
|
|
|
};
|
|
|
|
|
2019-06-14 07:36:47 +02:00
|
|
|
class Sql_cmd_create_table: public Sql_cmd_create_table_like
|
|
|
|
{
|
|
|
|
public:
|
|
|
|
enum_sql_command sql_command_code() const { return SQLCOM_CREATE_TABLE; }
|
|
|
|
};
|
|
|
|
|
|
|
|
class Sql_cmd_create_sequence: public Sql_cmd_create_table_like
|
|
|
|
{
|
|
|
|
public:
|
|
|
|
enum_sql_command sql_command_code() const { return SQLCOM_CREATE_SEQUENCE; }
|
|
|
|
};
|
|
|
|
|
2017-08-15 12:13:42 +02:00
|
|
|
|
|
|
|
/**
|
|
|
|
Sql_cmd_call represents the CALL statement.
|
|
|
|
*/
|
|
|
|
class Sql_cmd_call : public Sql_cmd
|
|
|
|
{
|
|
|
|
public:
|
|
|
|
class sp_name *m_name;
|
2017-08-18 21:36:42 +02:00
|
|
|
const class Sp_handler *m_handler;
|
|
|
|
Sql_cmd_call(class sp_name *name, const class Sp_handler *handler)
|
|
|
|
:m_name(name),
|
|
|
|
m_handler(handler)
|
2017-08-15 12:13:42 +02:00
|
|
|
{}
|
|
|
|
|
2023-02-07 12:57:20 +01:00
|
|
|
virtual ~Sql_cmd_call() = default;
|
2017-08-15 12:13:42 +02:00
|
|
|
|
|
|
|
/**
|
|
|
|
Execute a CALL statement at runtime.
|
|
|
|
@param thd the current thread.
|
|
|
|
@return false on success.
|
|
|
|
*/
|
|
|
|
bool execute(THD *thd);
|
|
|
|
|
|
|
|
virtual enum_sql_command sql_command_code() const
|
|
|
|
{
|
|
|
|
return SQLCOM_CALL;
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2012-08-14 16:23:34 +02:00
|
|
|
#endif // SQL_CMD_INCLUDED
|