An error occurred fetching the project authors.
  1. 11 Sep, 2021 1 commit
  2. 23 Jul, 2021 1 commit
    • Igor Babaev's avatar
      MDEV-25484 Crash when parsing query using derived table containing TVC · 9fde2bba
      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>
      9fde2bba
  3. 16 Jul, 2021 1 commit
    • Nikita Malyavin's avatar
      MDEV-23597 Assertion `marked_for_read()' failed while evaluating DEFAULT · c47e4aab
      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().
      c47e4aab
  4. 25 May, 2021 1 commit
    • Igor Babaev's avatar
      MDEV-23886 Reusing CTE inside a function fails with table doesn't exist · 04de6517
      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.
      04de6517
  5. 21 May, 2021 1 commit
    • Igor Babaev's avatar
      MDEV-23886 Reusing CTE inside a function fails with table doesn't exist · 43c9fcef
      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.
      43c9fcef
  6. 28 Apr, 2021 1 commit
    • Oleksandr Byelkin's avatar
      Bug#29363867: LOST CONNECTION TO MYSQL SERVER DURING QUERY · 24693c6f
      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;
      24693c6f
  7. 04 Mar, 2021 1 commit
    • Igor Babaev's avatar
      MDEV-22786 Crashes with nested table value constructors · 08d8bce5
      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
      08d8bce5
  8. 24 Jan, 2021 1 commit
  9. 11 Jan, 2021 1 commit
    • Sergei Golubchik's avatar
      MDEV-12161 Can't specify collation for virtual columns · 4c448836
      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
      4c448836
  10. 10 Dec, 2020 1 commit
  11. 04 Nov, 2020 1 commit
  12. 23 Oct, 2020 1 commit
    • Sergei Golubchik's avatar
      precedence bugfixing · 05a878c1
      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
      05a878c1
  13. 21 Oct, 2020 1 commit
    • Rinat Ibragimov's avatar
      MDEV-20945: BACKUP UNLOCK + FTWRL assertion failure · 709ba7dc
      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
      709ba7dc
  14. 06 Oct, 2020 1 commit
  15. 24 Sep, 2020 1 commit
  16. 20 Sep, 2020 5 commits
  17. 31 Aug, 2020 1 commit
  18. 13 Aug, 2020 1 commit
  19. 01 Aug, 2020 1 commit
    • Alexander Barkov's avatar
      MDEV-19632 Replication aborts with ER_SLAVE_CONVERSION_FAILED upon CREATE ... SELECT in ORACLE mode · d63631c3
      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.
      d63631c3
  20. 28 Jul, 2020 1 commit
  21. 19 May, 2020 1 commit
    • Alexander Barkov's avatar
      MDEV-21995 Server crashes in Item_field::real_type_handler with table value constructor · 06fb78c6
      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.
      06fb78c6
  22. 04 May, 2020 1 commit
    • Thirunarayanan Balathandayuthapani's avatar
      MDEV-16288 ALTER TABLE…ALGORITHM=DEFAULT does not override alter_algorithm · ec9908b2
      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
      ec9908b2
  23. 26 Feb, 2020 1 commit
  24. 10 Feb, 2020 1 commit
  25. 05 Feb, 2020 1 commit
  26. 14 Jan, 2020 1 commit
    • Sergei Petrunia's avatar
      MDEV-21341: Fix UBSAN failures: Issue Six · 5e5ae51b
      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.
      5e5ae51b
  27. 25 Nov, 2019 1 commit
  28. 22 Nov, 2019 1 commit
  29. 17 Oct, 2019 2 commits
  30. 23 Sep, 2019 1 commit
    • Igor Babaev's avatar
      MDEV-19956 Queries with subqueries containing UNION are not parsed · b4417142
      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.
      b4417142
  31. 20 Sep, 2019 2 commits
  32. 11 Sep, 2019 2 commits
  33. 01 Sep, 2019 1 commit