An error occurred fetching the project authors.
- 11 Sep, 2021 1 commit
-
-
Vladislav Vaintroub authored
-
- 23 Jul, 2021 1 commit
-
-
Igor Babaev authored
This patch fixes parsing problems concerning derived tables that use table value constructors (TVC) with LIMIT and ORDER BY clauses of the form ((VALUES ... LIMIT ...) ORDER BY ...) as dt The fix has to be applied only to 10.3 as 10.4 that employs a different grammar rules has no such problems. The test cases should be merged upstream. Approved by Oleksandr Byelkin <sanja@mariadb.com>
-
- 16 Jul, 2021 1 commit
-
-
Nikita Malyavin authored
The columns that are part of DEFAULT expression were not read-marked in statements like UPDATE...SET b=DEFAULT. The problem is `F(DEFAULT)` expression depends of the left-hand side of an assignment. However, setup_fields accepts only right-hand side value. Neither Item::fix_fields does. Suchwise, b=DEFAULT(b) works fine, because Item_default_field has information on what field it is default of: if (thd->mark_used_columns != MARK_COLUMNS_NONE) def_field->default_value->expr->update_used_tables(); in Item_default_value::fix_fields(). It is not reasonable to pass a left-hand side to Item:fix_fields, because the case is rare, so the rewrite b= F(DEFAULT) -> b= F(DEFAULT(b)) is made instead. Both UPDATE and multi-UPDATE are affected, however any form of INSERT is not: it marks all the fields in DEFAULT expressions for read in TABLE::mark_default_fields_for_write().
-
- 25 May, 2021 1 commit
-
-
Igor Babaev authored
In the code existed just before this patch binding of a table reference to the specification of the corresponding CTE happens in the function open_and_process_table(). If the table reference is not the first in the query the specification is cloned in the same way as the specification of a view is cloned for any reference of the view. This works fine for standalone queries, but does not work for stored procedures / functions for the following reason. When the first call of a stored procedure/ function SP is processed the body of SP is parsed. When a query of SP is parsed the info on each encountered table reference is put into a TABLE_LIST object linked into a global chain associated with the query. When parsing of the query is finished the basic info on the table references from this chain except table references to derived tables and information schema tables is put in one hash table associated with SP. When parsing of the body of SP is finished this hash table is used to construct TABLE_LIST objects for all table references mentioned in SP and link them into the list of such objects passed to a pre-locking process that calls open_and_process_table() for each table from the list. When a TABLE_LIST for a view is encountered the view is opened and its specification is parsed. For any table reference occurred in the specification a new TABLE_LIST object is created to be included into the list for pre-locking. After all objects in the pre-locking have been looked through the tables mentioned in the list are locked. Note that the objects referenced CTEs are just skipped here as it is impossible to resolve these references without any info on the context where they occur. Now the statements from the body of SP are executed one by one that. At the very beginning of the execution of a query the tables used in the query are opened and open_and_process_table() now is called for each table reference mentioned in the list of TABLE_LIST objects associated with the query that was built when the query was parsed. For each table reference first the reference is checked against CTEs definitions in whose scope it occurred. If such definition is found the reference is considered resolved and if this is not the first reference to the found CTE the the specification of the CTE is re-parsed and the result of the parsing is added to the parsing tree of the query as a sub-tree. If this sub-tree contains table references to other tables they are added to the list of TABLE_LIST objects associated with the query in order the referenced tables to be opened. When the procedure that opens the tables comes to the TABLE_LIST object created for a non-first reference to a CTE it discovers that the referenced table instance is not locked and reports an error. Thus processing non-first table references to a CTE similar to how references to view are processed does not work for queries used in stored procedures / functions. And the main problem is that the current pre-locking mechanism employed for stored procedures / functions does not allow to save the context in which a CTE reference occur. It's not trivial to save the info about the context where a CTE reference occurs while the resolution of the table reference cannot be done without this context and consequentially the specification for the table reference cannot be determined. This patch solves the above problem by moving resolution of all CTE references at the parsing stage. More exactly references to CTEs occurred in a query are resolved right after parsing of the query has finished. After resolution any CTE reference it is marked as a reference to to derived table. So it is excluded from the hash table created for pre-locking used base tables and view when the first call of a stored procedure / function is processed. This solution required recursive calls of the parser. The function THD::sql_parser() has been added specifically for recursive invocations of the parser.
-
- 21 May, 2021 1 commit
-
-
Igor Babaev authored
In the code existed just before this patch binding of a table reference to the specification of the corresponding CTE happens in the function open_and_process_table(). If the table reference is not the first in the query the specification is cloned in the same way as the specification of a view is cloned for any reference of the view. This works fine for standalone queries, but does not work for stored procedures / functions for the following reason. When the first call of a stored procedure/ function SP is processed the body of SP is parsed. When a query of SP is parsed the info on each encountered table reference is put into a TABLE_LIST object linked into a global chain associated with the query. When parsing of the query is finished the basic info on the table references from this chain except table references to derived tables and information schema tables is put in one hash table associated with SP. When parsing of the body of SP is finished this hash table is used to construct TABLE_LIST objects for all table references mentioned in SP and link them into the list of such objects passed to a pre-locking process that calls open_and_process_table() for each table from the list. When a TABLE_LIST for a view is encountered the view is opened and its specification is parsed. For any table reference occurred in the specification a new TABLE_LIST object is created to be included into the list for pre-locking. After all objects in the pre-locking have been looked through the tables mentioned in the list are locked. Note that the objects referenced CTEs are just skipped here as it is impossible to resolve these references without any info on the context where they occur. Now the statements from the body of SP are executed one by one that. At the very beginning of the execution of a query the tables used in the query are opened and open_and_process_table() now is called for each table reference mentioned in the list of TABLE_LIST objects associated with the query that was built when the query was parsed. For each table reference first the reference is checked against CTEs definitions in whose scope it occurred. If such definition is found the reference is considered resolved and if this is not the first reference to the found CTE the the specification of the CTE is re-parsed and the result of the parsing is added to the parsing tree of the query as a sub-tree. If this sub-tree contains table references to other tables they are added to the list of TABLE_LIST objects associated with the query in order the referenced tables to be opened. When the procedure that opens the tables comes to the TABLE_LIST object created for a non-first reference to a CTE it discovers that the referenced table instance is not locked and reports an error. Thus processing non-first table references to a CTE similar to how references to view are processed does not work for queries used in stored procedures / functions. And the main problem is that the current pre-locking mechanism employed for stored procedures / functions does not allow to save the context in which a CTE reference occur. It's not trivial to save the info about the context where a CTE reference occurs while the resolution of the table reference cannot be done without this context and consequentially the specification for the table reference cannot be determined. This patch solves the above problem by moving resolution of all CTE references at the parsing stage. More exactly references to CTEs occurred in a query are resolved right after parsing of the query has finished. After resolution any CTE reference it is marked as a reference to to derived table. So it is excluded from the hash table created for pre-locking used base tables and view when the first call of a stored procedure / function is processed. This solution required recursive calls of the parser. The function THD::sql_parser() has been added specifically for recursive invocations of the parser.
-
- 28 Apr, 2021 1 commit
-
-
Oleksandr Byelkin authored
The problem is that sharing default expression among set instruction leads to attempt access result field of function created in other instruction runtime MEM_ROOT and already freed (a bit different then MySQL problem). Fix is the same as in MySQL (but no optimisation for constant), turn DECLARE a, b, c type DEFAULT expr; to DECLARE a type DEFAULT expr, b type DEFAULT a, c type DEFAULT a;
-
- 04 Mar, 2021 1 commit
-
-
Igor Babaev authored
The bug caused crashes of the server when processing queries with nested table value constructors (TVC) . It happened because the grammar rules to parse TVC used the same global lists for both nested TVC and nesting TVC. As a result invalid select trees were constructed for queries with nested TVC and this led to crashes at the prepare stage. This patch provides its own lists structures for each TVC nest level. Besides the patch fixes a bug in the function wrap_tvc() that missed inheritance of the SELECT_LEX::exclude_from_table_unique_test for selects that wrapped TVCs. This inheritance is critical for specifications of derived tables that employ nested TVCs. Approved by dmitry.shulga@mariadb.com
-
- 24 Jan, 2021 1 commit
-
-
Sergei Golubchik authored
-
- 11 Jan, 2021 1 commit
-
-
Sergei Golubchik authored
sql standard (2016) allows <collate clause> in two places in the <column definition> - as a part of the <data type> or at the very end. Let's do that too. Side effect: in column/SP declaration `COLLATE cs_coll` automatically implies `CHARACTER SET cs` (unless charset was specified explicitly). See changes in sp-ucs2.result
-
- 10 Dec, 2020 1 commit
-
-
Sergei Golubchik authored
fix parsing of "1 IS NULL = 2"
-
- 04 Nov, 2020 1 commit
-
-
Daniel Black authored
Reviewed-by: vicentiu@mariadb.org
-
- 23 Oct, 2020 1 commit
-
-
Sergei Golubchik authored
fix printing precedence for BETWEEN, LIKE/ESCAPE, REGEXP, IN don't use precedence for printing CASE/WHEN/THEN/ELSE/END fix parsing precedence of BETWEEN, LIKE/ESCAPE, REGEXP, IN support predicate arguments for IN, BETWEEN, SOUNDS LIKE, LIKE/ESCAPE, REGEXP use %nonassoc for unary operators fix parsing of IS TRUE/FALSE/UNKNOWN/NULL remove parser_precedence test as superseded by the precedence test
-
- 21 Oct, 2020 1 commit
-
-
Rinat Ibragimov authored
MDEV-20945: BACKUP UNLOCK + FTWRL assertion failure | SIGSEGV in I_P_List from MDL_context::release_lock on INSERT w/ BACKUP LOCK (on optimized builds) | Assertion `ticket->m_duration == MDL_EXPLICIT' failed BACKUP LOCK behavior is modified so it won't be used wrong: - BACKUP LOCK should commit any active transactions. - BACKUP LOCK should not be allowed in stored procedures. - When BACKUP LOCK is active, don't allow any DDL's for that connection. - FTWRL is forbidden on the same connection while BACKUP LOCK is active. Reviewed-by: monty@mariadb.com
-
- 06 Oct, 2020 1 commit
-
-
Oleksandr Byelkin authored
MDEV-18163 Assertion `table_share->tmp_table != NO_TMP_TABLE || m_lock_type != 2' failed in handler::ha_rnd_next(); / Assertion `table_list->table' failed in find_field_in_table_ref / ERROR 1901 (on optimized builds) Add the same check for altering DEFAULT used as for CREATE TABLE.
-
- 24 Sep, 2020 1 commit
-
-
Daniel Black authored
Appoligies, had a dirty branch before pushing: This reverts commit 053653a2. This reverts commit 0ff89780. This reverts commit 85b08597. This reverts commit f3f45e46. This reverts commit a470b357. This reverts commit f8b8d202. This reverts commit 6b6f066f. This reverts commit a701e9e6. This reverts commit c1698386.
-
- 20 Sep, 2020 5 commits
-
-
Vicențiu Ciorbaru authored
* Maintain coding style in sql_yacc.yy in regards to optional clauses. * Remove unused variable from sql_acl.cc. * Update test case
-
Vicențiu Ciorbaru authored
-
Vicențiu Ciorbaru authored
-
Vicențiu Ciorbaru authored
Implemented the alter user syntax. Also tested that create user creates users accordingly.
-
Vicențiu Ciorbaru authored
Extend the syntax accepted by the grammar to account for the new create user and alter user syntax.
-
- 31 Aug, 2020 1 commit
-
-
Oleksandr Byelkin authored
Added system-SELECT to IF/WHILE/REPET/FOR for correct subqueries connecting. Added control of system/usual selects for correct error detection.
-
- 13 Aug, 2020 1 commit
-
-
Marko Mäkelä authored
Fix some more cases after merging commit 31aef3ae. Some warnings look possibly genuine, others are clearly bogus.
-
- 01 Aug, 2020 1 commit
-
-
Alexander Barkov authored
- Adding optional qualifiers to data types: CREATE TABLE t1 (a schema.DATE); Qualifiers now work only for three pre-defined schemas: mariadb_schema oracle_schema maxdb_schema These schemas are virtual (hard-coded) for now, but may turn into real databases on disk in the future. - mariadb_schema.TYPE now always resolves to a true MariaDB data type TYPE without sql_mode specific translations. - oracle_schema.DATE translates to MariaDB DATETIME. - maxdb_schema.TIMESTAMP translates to MariaDB DATETIME. - Fixing SHOW CREATE TABLE to use a qualifier for a data type TYPE if the current sql_mode translates TYPE to something else. The above changes fix the reported problem, so this script: SET sql_mode=ORACLE; CREATE TABLE t2 AS SELECT mariadb_date_column FROM t1; is now replicated as: SET sql_mode=ORACLE; CREATE TABLE t2 (mariadb_date_column mariadb_schema.DATE); and the slave can unambiguously treat DATE as the true MariaDB DATE without ORACLE specific translation to DATETIME. Similar, SET sql_mode=MAXDB; CREATE TABLE t2 AS SELECT mariadb_timestamp_column FROM t1; is now replicated as: SET sql_mode=MAXDB; CREATE TABLE t2 (mariadb_timestamp_column mariadb_schema.TIMESTAMP); so the slave treats TIMESTAMP as the true MariaDB TIMESTAMP without MAXDB specific translation to DATETIME.
-
- 28 Jul, 2020 1 commit
-
-
Oleksandr Byelkin authored
-
- 19 May, 2020 1 commit
-
-
Alexander Barkov authored
1. Code simplification: Item_default_value handled all these values: a. DEFAULT(field) b. DEFAULT c. IGNORE and had various conditions to distinguish (a) from (b) and from (c). Introducing a new abstract class Item_contextually_typed_value_specification, to handle (b) and (c), so the hierarchy now looks as follows: Item Item_result_field Item_ident Item_field Item_default_value - DEFAULT(field) Item_contextually_typed_value_specification Item_default_specification - DEFAULT Item_ignore_specification - IGNORE 2. Introducing a new virtual method is_evaluable_expression() to determine if an Item is: - a normal expression, so its val_xxx()/get_date() methods can be called - or a just an expression substitute, whose value methods cannot be called. 3. Disallowing Items that are not evalualble expressions in table value constructors.
-
- 04 May, 2020 1 commit
-
-
Thirunarayanan Balathandayuthapani authored
- ALTER_ALGORITHM should be substituted when there is no mention of algorithm in alter statement. - Introduced algorithm(thd) in Alter_info. It returns the user requested algorithm. If user doesn't specify algorithm explicitly then it returns alter_algorithm variable. - changed algorithm() to get_algorithm(thd) to return algorithm name for displaying the error. - set_requested_algorithm(algo_value) to avoid direct assignment on requested_algorithm variable. - Avoid direct access of requested_algorithm to encapsulate requested_algorithm variable
-
- 26 Feb, 2020 1 commit
-
-
Oleksandr Byelkin authored
Main select should be pushed first in case of SET STATEMENT.
-
- 10 Feb, 2020 1 commit
-
-
Alexey Botchkov authored
Mistake in syntax definition fixed - should be ALTER USER IF EXISTS, not ALTER IF EXISTS USER.
-
- 05 Feb, 2020 1 commit
-
-
Oleksandr Byelkin authored
MDEV-21616: Server crash when using "SET STATEMENT max_statement_time=0 FOR desc xxx" lead to collapse Main select should be pushed first.
-
- 14 Jan, 2020 1 commit
-
-
Sergei Petrunia authored
(Variant #2 of the patch, which keeps the sp_head object inside the MEM_ROOT that sp_head object owns) (10.3 requires extra work due to sp_package, will commit a separate patch for it) sp_head::operator new() and operator delete() were dereferencing sp_head* pointers to memory that didn't hold a valid sp_head object (it was not created/already destroyed). This caused UBSan to crash when looking up type information. Fixed by providing static sp_head::create() and sp_head::destroy() methods.
-
- 25 Nov, 2019 1 commit
-
-
Aleksey Midenkov authored
UPDATE, DELETE: replace linear search of current/historical records with vers_setup_conds(). Additional DML cases in view.test
-
- 22 Nov, 2019 1 commit
-
-
Aleksey Midenkov authored
MDEV-18957 UPDATE with LIMIT clause is wrong for versioned partitioned tables UPDATE, DELETE: replace linear search of current/historical records with vers_setup_conds(). Additional DML cases in view.test
-
- 17 Oct, 2019 2 commits
-
-
Oleksandr Byelkin authored
added forgotem WITH option to spacial case with INTO
-
Oleksandr Byelkin authored
Instead of checking lex->sql_command which does not corect in case of triggers mark tables for insert.
-
- 23 Sep, 2019 1 commit
-
-
Igor Babaev authored
Shift-Reduce conflicts prevented parsing some queries with subqueries that used set operations when the subqueries occurred in expressions or in IN predicands. The grammar rules for query expression were transformed in order to avoid these conflicts. New grammar rules employ an idea taken from MySQL 8.0.
-
- 20 Sep, 2019 2 commits
-
-
Anel Husakovic authored
-
Alexander Barkov authored
-
- 11 Sep, 2019 2 commits
-
-
Alexander Barkov authored
-
Alexander Barkov authored
-
- 01 Sep, 2019 1 commit
-
-
Aleksey Midenkov authored
Cleanup removes useless allocation.
-