mirror of
https://github.com/MariaDB/server.git
synced 2025-01-30 18:41:56 +01:00
3a9358a410
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> |
||
|---|---|---|
| .. | ||
| bitdata | ||
| cursors | ||
| datadict | ||
| include | ||
| lib | ||
| r | ||
| storedproc | ||
| t | ||
| triggers | ||
| views | ||
| disabled.def | ||
| README.txt | ||
2008-02-29 Matthias Leich
=========================
1. The testsuite "funcs_1" is mostly intended for additional (compared
to the common regression tests stored in mysql-test/t) checks
of features (VIEWS, INFORMATION_SCHEMA, STORED PROCEDURES,...)
introduced with MySQL 5.0.
2. There were some extensions of this suite when new information_schema
views were introduced. But in most cases the tests for these views
were stored within the regression testsuite (mysql-test/t).
INFORMATION_SCHEMA views introduced with MySQL 5.1
==================================================
ENGINES (partially tested here)
EVENTS (partially tested here)
FILES
GLOBAL_STATUS
GLOBAL_VARIABLES
PARTITIONS
PLUGINS
PROCESSLIST (full tested here)
PROFILING
REFERENTIAL_CONSTRAINTS
SESSION_STATUS
SESSION_VARIABLES
3. Some hints for maintainers of this suite:
- SHOW TABLES ... LIKE '<pattern>'
does a case sensitive comparison between the tablename and
the pattern.
The names of the tables within the informationschema are in uppercase.
So please use something like
SHOW TABLES FOR information_schema LIKE 'TABLES'
when you intend to get the same non empty result set on OS with and
without case sensitive filesystems and default configuration.
- The name of the data dictionary is 'information_schema' (lowercase).
- Server on OS with filesystem with case sensitive filenames
(= The files 'abc' and 'Abc' can coexist.)
+ default configuration
Example of behaviour:
DROP DATABASE information_schema;
ERROR 42000: Access denied for user ... to database 'information_schema'
DROP DATABASE INFORMATION_SCHEMA;
ERROR 42000: Access denied for user ... to database 'INFORMATION_SCHEMA'
- Try to unify results by
--replace_result $engine_type <engine_to_be_tested>
if we could expect that the results for storage engine variants of a
test differ only in the engine names.
This makes future maintenance easier.
- Avoid the use of include/show_msg*.inc.
They produce "SQL" noise which annoys during server debugging and can be
easy replaced by "--echo ...".