1
0
mirror of https://github.com/MariaDB/server.git synced 2025-07-21 21:22:27 +03:00
Commit Graph

9 Commits

Author SHA1 Message Date
45531949ae Merge 10.2 into 10.3 2018-12-18 09:15:41 +02:00
3074beaad6 MDEV-17387 MariaDB Server giving wrong error while executing select query from procedure
Changing the way how a cursor is opened to fetch its structure only,
e.g. for a cursor FOR loop record variable.

The old methods with setting thd->lex->limit_rows_examined to an Item_uint(0)
was not reliable and could push these messages into diagnostics area:

  The query examined at least 1 rows, which exceeds LIMIT ROWS EXAMINED (0)

The new method should be more reliable, as it completely prevents the call
of do_select() in JOIN::exec_inner() during the cursor structure discovery,
so the execution of the cursor SELECT query returns immediately after the
preparation step (when the result row structure becomes known),
without even entering the code that fetches the result rows.
2018-11-09 09:56:02 +04:00
a8caa8e04a MDEV-12854 Synchronize CREATE..SELECT data type and result set metadata data type for INT functions 2017-05-20 16:29:11 +04:00
e1cff0ac5d MDEV-12441 Variables declared after cursors with parameters lose values
Parse context frames (sp_pcontext) can have holes in variable run-time offsets,
the missing offsets reside on the children contexts in such cases.

Example:

  CREATE PROCEDURE p1() AS
    x0 INT:=100;        -- context 0, position 0, run-time 0
    CURSOR cur(
      p0 INT,           -- context 1, position 0, run-time 1
      p1 INT            -- context 1, position 1, run-time 2
    ) IS SELECT p0, p1;
    x1 INT:=101;        -- context 0, position 1, run-time 3
  BEGIN
    ...
  END;

Fixing a few methods to take this into account:
- sp_pcontext::find_variable()
- sp_pcontext::retrieve_field_definitions()
- LEX::sp_variable_declarations_init()
- LEX::sp_variable_declarations_finalize()
- LEX::sp_variable_declarations_rowtype_finalize()
- LEX::sp_variable_declarations_with_ref_finalize()

Adding a convenience method:

  sp_pcontext::get_last_context_variable(uint offset_from_the_end);

to access variables from the end, rather than from the beginning.
This helps to loop through the context variable array (m_vars)
on the fragment that does not have any holes.

Additionally, renaming sp_pcontext::find_context_variable() to
sp_pcontext::get_context_variable(). This method simply returns
the variable by its index. So let's rename to avoid assumptions
that some heavy lookup is going on inside.
2017-04-05 15:03:02 +04:00
400de20279 MDEV-12209 sql_mode=ORACLE: Syntax error in a OPEN cursor with parameters makes the server crash
The bug was introduced in the patch for "MDEV-10597 Cursors with parameters".
The LEX created in assignment_source_expr was not put into
thd->lex->sphead->m_lex (the stack of LEX'es), so syntax error in "expr"
caused a wrong memory cleanup in sp_head::~sp_head().

The fix changes the code to use sp_head::push_lex() followed by
sp_head::restore_lex(), like it happens in all other similar cases.
2017-04-05 15:02:58 +04:00
d836f52be5 MDEV-12007 Allow ROW variables as a cursor FETCH target 2017-04-05 15:02:56 +04:00
46d076d67a MDEV-10577 sql_mode=ORACLE: %TYPE in variable declarations 2017-04-05 15:02:54 +04:00
f8a714c848 MDEV-10597 Cursors with parameters 2017-04-05 15:02:53 +04:00
76714a5c9a MDEV-10582 sql_mode=ORACLE: explicit cursor attributes %ISOPEN, %ROWCOUNT, %FOUND, %NOTFOUND 2017-04-05 15:02:51 +04:00