Simplistic, experimental framework for Stored Procedures (SPs).
Implements creation and dropping of PROCEDUREs, IN, OUT, and INOUT parameters,
single-statement procedures, rudimentary multi-statement (begin-end) prodedures
(when the client can handle it), and local variables.
Missing most of the embedded SQL language, all attributes, FUNCTIONs, error handling,
reparses procedures at each call (no caching), etc, etc.
Certainly buggy too, but procedures can actually be created and called....
2002-12-08 19:59:22 +01:00
|
|
|
/* -*- C++ -*- */
|
|
|
|
/* Copyright (C) 2002 MySQL AB
|
|
|
|
|
|
|
|
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
|
2006-12-23 20:17:15 +01:00
|
|
|
the Free Software Foundation; version 2 of the License.
|
Simplistic, experimental framework for Stored Procedures (SPs).
Implements creation and dropping of PROCEDUREs, IN, OUT, and INOUT parameters,
single-statement procedures, rudimentary multi-statement (begin-end) prodedures
(when the client can handle it), and local variables.
Missing most of the embedded SQL language, all attributes, FUNCTIONs, error handling,
reparses procedures at each call (no caching), etc, etc.
Certainly buggy too, but procedures can actually be created and called....
2002-12-08 19:59:22 +01:00
|
|
|
|
|
|
|
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
|
|
|
|
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */
|
|
|
|
|
|
|
|
#ifndef _SP_HEAD_H_
|
|
|
|
#define _SP_HEAD_H_
|
|
|
|
|
2005-05-27 12:03:37 +02:00
|
|
|
#ifdef USE_PRAGMA_INTERFACE
|
Simplistic, experimental framework for Stored Procedures (SPs).
Implements creation and dropping of PROCEDUREs, IN, OUT, and INOUT parameters,
single-statement procedures, rudimentary multi-statement (begin-end) prodedures
(when the client can handle it), and local variables.
Missing most of the embedded SQL language, all attributes, FUNCTIONs, error handling,
reparses procedures at each call (no caching), etc, etc.
Certainly buggy too, but procedures can actually be created and called....
2002-12-08 19:59:22 +01:00
|
|
|
#pragma interface /* gcc class implementation */
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#include <stddef.h>
|
|
|
|
|
2003-02-21 17:37:05 +01:00
|
|
|
// Values for the type enum. This reflects the order of the enum declaration
|
|
|
|
// in the CREATE TABLE command.
|
|
|
|
#define TYPE_ENUM_FUNCTION 1
|
|
|
|
#define TYPE_ENUM_PROCEDURE 2
|
2004-09-07 14:29:46 +02:00
|
|
|
#define TYPE_ENUM_TRIGGER 3
|
2003-02-21 17:37:05 +01:00
|
|
|
|
2003-02-26 19:22:29 +01:00
|
|
|
Item_result
|
|
|
|
sp_map_result_type(enum enum_field_types type);
|
|
|
|
|
2005-12-07 15:01:17 +01:00
|
|
|
Item::Type
|
|
|
|
sp_map_item_type(enum enum_field_types type);
|
|
|
|
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
uint
|
|
|
|
sp_get_flags_for_command(LEX *lex);
|
2004-08-06 13:47:01 +02:00
|
|
|
|
2002-12-16 15:40:44 +01:00
|
|
|
struct sp_label;
|
Simplistic, experimental framework for Stored Procedures (SPs).
Implements creation and dropping of PROCEDUREs, IN, OUT, and INOUT parameters,
single-statement procedures, rudimentary multi-statement (begin-end) prodedures
(when the client can handle it), and local variables.
Missing most of the embedded SQL language, all attributes, FUNCTIONs, error handling,
reparses procedures at each call (no caching), etc, etc.
Certainly buggy too, but procedures can actually be created and called....
2002-12-08 19:59:22 +01:00
|
|
|
class sp_instr;
|
2006-01-26 17:26:25 +01:00
|
|
|
class sp_instr_opt_meta;
|
2005-11-04 15:37:39 +01:00
|
|
|
class sp_instr_jump_if_not;
|
2003-09-16 14:26:08 +02:00
|
|
|
struct sp_cond_type;
|
2006-04-07 16:53:15 +02:00
|
|
|
struct sp_variable;
|
2003-09-16 14:26:08 +02:00
|
|
|
|
2004-02-17 17:36:53 +01:00
|
|
|
class sp_name : public Sql_alloc
|
|
|
|
{
|
|
|
|
public:
|
|
|
|
|
|
|
|
LEX_STRING m_db;
|
|
|
|
LEX_STRING m_name;
|
|
|
|
LEX_STRING m_qname;
|
2005-07-09 19:51:59 +02:00
|
|
|
/*
|
|
|
|
Key representing routine in the set of stored routines used by statement.
|
|
|
|
Consists of 1-byte routine type and m_qname (which usually refences to
|
|
|
|
same buffer). Note that one must complete initialization of the key by
|
|
|
|
calling set_routine_type().
|
|
|
|
*/
|
|
|
|
LEX_STRING m_sroutines_key;
|
2007-03-27 18:31:44 +02:00
|
|
|
bool m_explicit_name; /**< Prepend the db name? */
|
2004-02-17 17:36:53 +01:00
|
|
|
|
2007-03-27 18:31:44 +02:00
|
|
|
sp_name(LEX_STRING db, LEX_STRING name, bool use_explicit_name)
|
|
|
|
: m_db(db), m_name(name), m_explicit_name(use_explicit_name)
|
2004-02-17 17:36:53 +01:00
|
|
|
{
|
2005-07-09 19:51:59 +02:00
|
|
|
m_qname.str= m_sroutines_key.str= 0;
|
|
|
|
m_qname.length= m_sroutines_key.length= 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
Creates temporary sp_name object from key, used mainly
|
|
|
|
for SP-cache lookups.
|
|
|
|
*/
|
|
|
|
sp_name(char *key, uint key_len)
|
|
|
|
{
|
|
|
|
m_sroutines_key.str= key;
|
|
|
|
m_sroutines_key.length= key_len;
|
|
|
|
m_name.str= m_qname.str= key + 1;
|
|
|
|
m_name.length= m_qname.length= key_len - 1;
|
|
|
|
m_db.str= 0;
|
|
|
|
m_db.length= 0;
|
2007-03-27 18:31:44 +02:00
|
|
|
m_explicit_name= false;
|
2004-02-17 17:36:53 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
// Init. the qualified name from the db and name.
|
|
|
|
void init_qname(THD *thd); // thd for memroot allocation
|
|
|
|
|
2005-07-09 19:51:59 +02:00
|
|
|
void set_routine_type(char type)
|
|
|
|
{
|
|
|
|
m_sroutines_key.str[0]= type;
|
|
|
|
}
|
|
|
|
|
2004-02-17 17:36:53 +01:00
|
|
|
~sp_name()
|
|
|
|
{}
|
|
|
|
};
|
|
|
|
|
2004-03-11 17:18:59 +01:00
|
|
|
|
2006-01-11 15:11:05 +01:00
|
|
|
bool
|
2007-04-03 13:13:27 +02:00
|
|
|
check_routine_name(LEX_STRING *ident);
|
2004-03-11 17:18:59 +01:00
|
|
|
|
2005-06-15 19:58:35 +02:00
|
|
|
class sp_head :private Query_arena
|
Simplistic, experimental framework for Stored Procedures (SPs).
Implements creation and dropping of PROCEDUREs, IN, OUT, and INOUT parameters,
single-statement procedures, rudimentary multi-statement (begin-end) prodedures
(when the client can handle it), and local variables.
Missing most of the embedded SQL language, all attributes, FUNCTIONs, error handling,
reparses procedures at each call (no caching), etc, etc.
Certainly buggy too, but procedures can actually be created and called....
2002-12-08 19:59:22 +01:00
|
|
|
{
|
|
|
|
sp_head(const sp_head &); /* Prevent use of these */
|
|
|
|
void operator=(sp_head &);
|
|
|
|
|
2005-06-22 09:59:13 +02:00
|
|
|
MEM_ROOT main_mem_root;
|
Simplistic, experimental framework for Stored Procedures (SPs).
Implements creation and dropping of PROCEDUREs, IN, OUT, and INOUT parameters,
single-statement procedures, rudimentary multi-statement (begin-end) prodedures
(when the client can handle it), and local variables.
Missing most of the embedded SQL language, all attributes, FUNCTIONs, error handling,
reparses procedures at each call (no caching), etc, etc.
Certainly buggy too, but procedures can actually be created and called....
2002-12-08 19:59:22 +01:00
|
|
|
public:
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
/* Possible values of m_flags */
|
2005-09-07 17:39:47 +02:00
|
|
|
enum {
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
HAS_RETURN= 1, // For FUNCTIONs only: is set if has RETURN
|
|
|
|
MULTI_RESULTS= 8, // Is set if a procedure with SELECT(s)
|
|
|
|
CONTAINS_DYNAMIC_SQL= 16, // Is set if a procedure with PREPARE/EXECUTE
|
2005-09-13 17:16:12 +02:00
|
|
|
IS_INVOKED= 32, // Is set if this sp_head is being used
|
2005-11-16 13:09:06 +01:00
|
|
|
HAS_SET_AUTOCOMMIT_STMT= 64,// Is set if a procedure with 'set autocommit'
|
|
|
|
/* Is set if a procedure with COMMIT (implicit or explicit) | ROLLBACK */
|
2006-03-01 02:34:22 +01:00
|
|
|
HAS_COMMIT_OR_ROLLBACK= 128,
|
2006-03-01 16:27:57 +01:00
|
|
|
LOG_SLOW_STATEMENTS= 256, // Used by events
|
* Mixed replication mode * :
1) Fix for BUG#19630 "stored function inserting into two auto_increment breaks
statement-based binlog":
a stored function inserting into two such tables may fail to replicate
(inserting wrong data in the slave's copy of the second table) if the slave's
second table had an internal auto_increment counter different from master's.
Because the auto_increment value autogenerated by master for the 2nd table
does not go into binlog, only the first does, so the slave lacks information.
To fix this, if running in mixed binlogging mode, if the stored function or
trigger plans to update two different tables both having auto_increment
columns, we switch to row-based for the whole function.
We don't have a simple solution for statement-based binlogging mode, there
the bug remains and will be documented as a known problem.
Re-enabling rpl_switch_stm_row_mixed.
2) Fix for BUG#20630 "Mixed binlogging mode does not work with stored
functions, triggers, views", which was a documented limitation (in mixed
mode, we didn't detect that a stored function's execution needed row-based
binlogging (due to some UUID() call for example); same for
triggers, same for views (a view created from a SELECT UUID(), and doing
INSERT INTO sometable SELECT theview; would not replicate row-based).
This is implemented by, after parsing a routine's body, remembering in sp_head
that this routine needs row-based binlogging. Then when this routine is used,
the caller is marked to require row-based binlogging too.
Same for views: when we parse a view and detect that its SELECT needs
row-based binary logging, we mark the calling LEX as such.
3) Fix for BUG#20499 "mixed mode with temporary table breaks binlog":
a temporary table containing e.g. UUID has its changes not binlogged,
so any query updating a permanent table with data from the temporary table
will run wrongly on slave. Solution: in mixed mode we don't switch back
from row-based to statement-based when there exists temporary tables.
4) Attempt to test mysqlbinlog on a binlog generated by mysqlbinlog;
impossible due to BUG#11312 and BUG#20329, but test is in place for when
they are fixed.
2006-07-09 17:00:47 +02:00
|
|
|
LOG_GENERAL_LOG= 512, // Used by events
|
2006-08-30 21:09:47 +02:00
|
|
|
BINLOG_ROW_BASED_IF_MIXED= 1024,
|
2006-08-25 15:51:29 +02:00
|
|
|
HAS_SQLCOM_RESET= 2048,
|
|
|
|
HAS_SQLCOM_FLUSH= 4096
|
2005-09-07 17:39:47 +02:00
|
|
|
};
|
Simplistic, experimental framework for Stored Procedures (SPs).
Implements creation and dropping of PROCEDUREs, IN, OUT, and INOUT parameters,
single-statement procedures, rudimentary multi-statement (begin-end) prodedures
(when the client can handle it), and local variables.
Missing most of the embedded SQL language, all attributes, FUNCTIONs, error handling,
reparses procedures at each call (no caching), etc, etc.
Certainly buggy too, but procedures can actually be created and called....
2002-12-08 19:59:22 +01:00
|
|
|
|
2005-11-16 13:09:06 +01:00
|
|
|
/* TYPE_ENUM_FUNCTION, TYPE_ENUM_PROCEDURE or TYPE_ENUM_TRIGGER */
|
|
|
|
int m_type;
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
uint m_flags; // Boolean attributes of a stored routine
|
2005-12-07 15:01:17 +01:00
|
|
|
|
|
|
|
create_field m_return_field_def; /* This is used for FUNCTIONs only. */
|
|
|
|
|
2007-03-27 19:09:56 +02:00
|
|
|
const char *m_tmp_query; // Temporary pointer to sub query string
|
2003-12-10 19:05:37 +01:00
|
|
|
st_sp_chistics *m_chistics;
|
2005-07-28 21:39:11 +02:00
|
|
|
ulong m_sql_mode; // For SHOW CREATE and execution
|
2004-02-17 17:36:53 +01:00
|
|
|
LEX_STRING m_qname; // db.name
|
|
|
|
LEX_STRING m_db;
|
2003-12-12 14:05:29 +01:00
|
|
|
LEX_STRING m_name;
|
|
|
|
LEX_STRING m_params;
|
|
|
|
LEX_STRING m_body;
|
|
|
|
LEX_STRING m_defstr;
|
2003-12-13 16:40:52 +01:00
|
|
|
LEX_STRING m_definer_user;
|
|
|
|
LEX_STRING m_definer_host;
|
2003-12-12 14:05:29 +01:00
|
|
|
longlong m_created;
|
|
|
|
longlong m_modified;
|
2005-11-23 00:11:19 +01:00
|
|
|
/* Recursion level of the current SP instance. The levels are numbered from 0 */
|
|
|
|
ulong m_recursion_level;
|
|
|
|
/*
|
|
|
|
A list of diferent recursion level instances for the same procedure.
|
|
|
|
For every recursion level we have a sp_head instance. This instances
|
|
|
|
connected in the list. The list ordered by increasing recursion level
|
|
|
|
(m_recursion_level).
|
|
|
|
*/
|
|
|
|
sp_head *m_next_cached_sp;
|
|
|
|
/*
|
|
|
|
Pointer to the first element of the above list
|
|
|
|
*/
|
|
|
|
sp_head *m_first_instance;
|
|
|
|
/*
|
|
|
|
Pointer to the first free (non-INVOKED) routine in the list of
|
|
|
|
cached instances for this SP. This pointer is set only for the first
|
|
|
|
SP in the list of instences (see above m_first_cached_sp pointer).
|
|
|
|
The pointer equal to 0 if we have no free instances.
|
|
|
|
For non-first instance value of this pointer meanless (point to itself);
|
|
|
|
*/
|
|
|
|
sp_head *m_first_free_instance;
|
|
|
|
/*
|
|
|
|
Pointer to the last element in the list of instances of the SP.
|
|
|
|
For non-first instance value of this pointer meanless (point to itself);
|
|
|
|
*/
|
|
|
|
sp_head *m_last_cached_sp;
|
2005-03-04 14:35:28 +01:00
|
|
|
/*
|
2005-07-09 19:51:59 +02:00
|
|
|
Set containing names of stored routines used by this routine.
|
|
|
|
Note that unlike elements of similar set for statement elements of this
|
|
|
|
set are not linked in one list. Because of this we are able save memory
|
|
|
|
by using for this set same objects that are used in 'sroutines' sets
|
|
|
|
for statements of which this stored routine consists.
|
2005-03-04 14:35:28 +01:00
|
|
|
*/
|
2005-07-09 19:51:59 +02:00
|
|
|
HASH m_sroutines;
|
2003-12-12 14:05:29 +01:00
|
|
|
// Pointers set during parsing
|
2007-04-26 05:38:12 +02:00
|
|
|
const char *m_param_begin;
|
|
|
|
const char *m_param_end;
|
|
|
|
const char *m_body_begin;
|
2002-12-17 10:01:52 +01:00
|
|
|
|
2005-09-20 20:20:38 +02:00
|
|
|
/*
|
|
|
|
Security context for stored routine which should be run under
|
|
|
|
definer privileges.
|
|
|
|
*/
|
|
|
|
Security_context m_security_ctx;
|
2005-09-15 21:29:07 +02:00
|
|
|
|
2003-06-29 18:15:17 +02:00
|
|
|
static void *
|
|
|
|
operator new(size_t size);
|
|
|
|
|
2004-05-26 13:28:35 +02:00
|
|
|
static void
|
2003-06-29 18:15:17 +02:00
|
|
|
operator delete(void *ptr, size_t size);
|
|
|
|
|
2003-07-01 17:19:48 +02:00
|
|
|
sp_head();
|
|
|
|
|
|
|
|
// Initialize after we have reset mem_root
|
|
|
|
void
|
2003-12-12 14:05:29 +01:00
|
|
|
init(LEX *lex);
|
|
|
|
|
2006-07-27 15:57:43 +02:00
|
|
|
/* Copy sp name from parser. */
|
|
|
|
void
|
|
|
|
init_sp_name(THD *thd, sp_name *spname);
|
|
|
|
|
2003-12-12 14:05:29 +01:00
|
|
|
// Initialize strings after parsing header
|
|
|
|
void
|
2006-07-27 15:57:43 +02:00
|
|
|
init_strings(THD *thd, LEX *lex);
|
2003-11-17 18:21:36 +01:00
|
|
|
|
Simplistic, experimental framework for Stored Procedures (SPs).
Implements creation and dropping of PROCEDUREs, IN, OUT, and INOUT parameters,
single-statement procedures, rudimentary multi-statement (begin-end) prodedures
(when the client can handle it), and local variables.
Missing most of the embedded SQL language, all attributes, FUNCTIONs, error handling,
reparses procedures at each call (no caching), etc, etc.
Certainly buggy too, but procedures can actually be created and called....
2002-12-08 19:59:22 +01:00
|
|
|
int
|
|
|
|
create(THD *thd);
|
2004-05-26 13:28:35 +02:00
|
|
|
|
2003-06-29 18:15:17 +02:00
|
|
|
virtual ~sp_head();
|
|
|
|
|
2003-04-02 20:42:28 +02:00
|
|
|
// Free memory
|
|
|
|
void
|
|
|
|
destroy();
|
|
|
|
|
2006-07-13 15:12:31 +02:00
|
|
|
bool
|
|
|
|
execute_trigger(THD *thd, const char *db, const char *table,
|
|
|
|
GRANT_INFO *grant_onfo);
|
|
|
|
|
2005-12-07 15:01:17 +01:00
|
|
|
bool
|
|
|
|
execute_function(THD *thd, Item **args, uint argcount, Field *return_fld);
|
2003-02-26 19:22:29 +01:00
|
|
|
|
2005-12-07 15:01:17 +01:00
|
|
|
bool
|
2003-02-26 19:22:29 +01:00
|
|
|
execute_procedure(THD *thd, List<Item> *args);
|
Simplistic, experimental framework for Stored Procedures (SPs).
Implements creation and dropping of PROCEDUREs, IN, OUT, and INOUT parameters,
single-statement procedures, rudimentary multi-statement (begin-end) prodedures
(when the client can handle it), and local variables.
Missing most of the embedded SQL language, all attributes, FUNCTIONs, error handling,
reparses procedures at each call (no caching), etc, etc.
Certainly buggy too, but procedures can actually be created and called....
2002-12-08 19:59:22 +01:00
|
|
|
|
2003-11-17 18:21:36 +01:00
|
|
|
int
|
|
|
|
show_create_procedure(THD *thd);
|
|
|
|
|
|
|
|
int
|
|
|
|
show_create_function(THD *thd);
|
|
|
|
|
2004-05-26 13:28:35 +02:00
|
|
|
void
|
|
|
|
add_instr(sp_instr *instr);
|
Simplistic, experimental framework for Stored Procedures (SPs).
Implements creation and dropping of PROCEDUREs, IN, OUT, and INOUT parameters,
single-statement procedures, rudimentary multi-statement (begin-end) prodedures
(when the client can handle it), and local variables.
Missing most of the embedded SQL language, all attributes, FUNCTIONs, error handling,
reparses procedures at each call (no caching), etc, etc.
Certainly buggy too, but procedures can actually be created and called....
2002-12-08 19:59:22 +01:00
|
|
|
|
|
|
|
inline uint
|
|
|
|
instructions()
|
|
|
|
{
|
|
|
|
return m_instr.elements;
|
|
|
|
}
|
|
|
|
|
2003-09-16 14:26:08 +02:00
|
|
|
inline sp_instr *
|
|
|
|
last_instruction()
|
|
|
|
{
|
|
|
|
sp_instr *i;
|
|
|
|
|
|
|
|
get_dynamic(&m_instr, (gptr)&i, m_instr.elements-1);
|
|
|
|
return i;
|
|
|
|
}
|
|
|
|
|
Simplistic, experimental framework for Stored Procedures (SPs).
Implements creation and dropping of PROCEDUREs, IN, OUT, and INOUT parameters,
single-statement procedures, rudimentary multi-statement (begin-end) prodedures
(when the client can handle it), and local variables.
Missing most of the embedded SQL language, all attributes, FUNCTIONs, error handling,
reparses procedures at each call (no caching), etc, etc.
Certainly buggy too, but procedures can actually be created and called....
2002-12-08 19:59:22 +01:00
|
|
|
// Resets lex in 'thd' and keeps a copy of the old one.
|
|
|
|
void
|
|
|
|
reset_lex(THD *thd);
|
|
|
|
|
|
|
|
// Restores lex in 'thd' from our copy, but keeps some status from the
|
|
|
|
// one in 'thd', like ptr, tables, fields, etc.
|
|
|
|
void
|
|
|
|
restore_lex(THD *thd);
|
|
|
|
|
2002-12-16 15:40:44 +01:00
|
|
|
// Put the instruction on the backpatch list, associated with the label.
|
2002-12-11 14:24:29 +01:00
|
|
|
void
|
2002-12-16 15:40:44 +01:00
|
|
|
push_backpatch(sp_instr *, struct sp_label *);
|
2002-12-11 14:24:29 +01:00
|
|
|
|
2002-12-16 15:40:44 +01:00
|
|
|
// Update all instruction with this label in the backpatch list to
|
|
|
|
// the current position.
|
2002-12-11 14:24:29 +01:00
|
|
|
void
|
2002-12-16 15:40:44 +01:00
|
|
|
backpatch(struct sp_label *);
|
2002-12-11 14:24:29 +01:00
|
|
|
|
2005-11-04 15:37:39 +01:00
|
|
|
// Start a new cont. backpatch level. If 'i' is NULL, the level is just incr.
|
|
|
|
void
|
2006-01-26 17:26:25 +01:00
|
|
|
new_cont_backpatch(sp_instr_opt_meta *i);
|
2005-11-04 15:37:39 +01:00
|
|
|
|
|
|
|
// Add an instruction to the current level
|
|
|
|
void
|
2006-01-26 17:26:25 +01:00
|
|
|
add_cont_backpatch(sp_instr_opt_meta *i);
|
2005-11-04 15:37:39 +01:00
|
|
|
|
|
|
|
// Backpatch (and pop) the current level to the current position.
|
|
|
|
void
|
|
|
|
do_cont_backpatch();
|
|
|
|
|
2003-02-21 17:37:05 +01:00
|
|
|
char *name(uint *lenp = 0) const
|
|
|
|
{
|
|
|
|
if (lenp)
|
2003-04-03 16:00:09 +02:00
|
|
|
*lenp= m_name.length;
|
|
|
|
return m_name.str;
|
2003-02-21 17:37:05 +01:00
|
|
|
}
|
|
|
|
|
2003-12-12 14:05:29 +01:00
|
|
|
char *create_string(THD *thd, ulong *lenp);
|
|
|
|
|
2005-12-07 15:01:17 +01:00
|
|
|
Field *create_result_field(uint field_max_length, const char *field_name,
|
|
|
|
TABLE *table);
|
|
|
|
|
|
|
|
bool fill_field_definition(THD *thd, LEX *lex,
|
|
|
|
enum enum_field_types field_type,
|
|
|
|
create_field *field_def);
|
2003-02-26 19:22:29 +01:00
|
|
|
|
2005-11-10 20:25:03 +01:00
|
|
|
void set_info(longlong created, longlong modified,
|
2004-06-09 14:19:43 +02:00
|
|
|
st_sp_chistics *chistics, ulong sql_mode);
|
2003-06-29 18:15:17 +02:00
|
|
|
|
2006-01-05 23:47:49 +01:00
|
|
|
void set_definer(const char *definer, uint definerlen);
|
2006-03-02 13:18:49 +01:00
|
|
|
void set_definer(const LEX_STRING *user_name, const LEX_STRING *host_name);
|
2005-11-10 20:25:03 +01:00
|
|
|
|
2004-03-11 17:18:59 +01:00
|
|
|
void reset_thd_mem_root(THD *thd);
|
|
|
|
|
|
|
|
void restore_thd_mem_root(THD *thd);
|
2003-06-29 18:15:17 +02:00
|
|
|
|
Bug#19194 (Right recursion in parser for CASE causes excessive stack usage,
limitation)
Note to the reviewer
====================
Warning: reviewing this patch is somewhat involved.
Due to the nature of several issues all affecting the same area,
fixing separately each issue is not practical, since each fix can not be
implemented and tested independently.
In particular, the issues with
- rule recursion
- nested case statements
- forward jump resolution (backpatch list)
are tightly coupled (see below).
Definitions
===========
The expression
CASE expr
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Simple Case Expression".
The expression
CASE
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Searched Case Expression".
The statement
CASE expr
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Simple Case Statement".
The statement
CASE
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Searched Case Statement".
A "Left Recursive" rule is like
list:
element
| list element
;
A "Right Recursive" rule is like
list:
element
| element list
;
Left and right recursion produces the same language, the difference only
affects the *order* in which the text is parsed.
In a descendant parser (usually written manually), right recursion works
very well, and is typically implemented with a while loop.
In an ascendant parser (yacc/bison) left recursion works very well,
and is implemented naturally by the parser stack.
In both cases, using the wrong type or recursion is very bad and should be
avoided, as it causes technical issues with the parser implementation.
Before this change
==================
The "Simple Case Expression" and "Searched Case Expression" were both
implemented by the "when_list" and "when_list2" rules, which are left
recursive (ok).
These rules, however, used lex->when_list instead of using the parser stack,
which is more complex that necessary, and potentially dangerous because
of other rules using THD::reset_lex.
The "Simple Case Statement" and "Searched Case Statements" were implemented
by the "sp_case", "sp_whens" and in part by "sp_proc_stmt" rules.
Both cases were right recursive (bad).
The grammar involved was convoluted, and is assumed to be the results of
tweaks to get the code generation to work, but is not what someone would
naturally write.
In addition, using a common rule for both "Simple" and "Searched" case
statements was implemented with sp_head::m_flags |= IN_SIMPLE_CASE,
which is a flag and not a stack, and therefore does not take into account
*nested* case statements. This leads to incorrect generated code, and either
a server crash or an incorrect result.
With regards to the backpatch mechanism, a *different* backpatch list was
created for each jump from "WHEN expr THEN stmt" to "END CASE", which
relied on the grammar to be right recursive.
This is a mis-use of the backpatch list, since this list can resolve
multiple references to the same target at once.
The optimizer algorithm used to detect dead code in the "assembly" SQL
instructions, implemented by sp_head::opt_mark(uint ip), was recursive
in some cases (a conditional jump pointing forward to another conditional
jump).
In case of specially crafted code, like
- a long list of "IF expr THEN stmt END IF"
- a long CASE statement
this would actually cause a server crash with a stack overflow.
In general, having a stack that grows proportionally with user data (the
SQL code given by the client in a CREATE PROCEDURE) is to be avoided.
In debug builds only, creating a SP / SF / Trigger which had a significant
amount of code would spend --literally-- several minutes in sp_head::create,
because of the debug code involved with DBUG_PRINT("info", ("Code %s ...
There are several issues with this code:
- in a CASE with 5 000 WHEN, there are 15 000 instructions generated,
which create a sting representation of the code which is 500 000 bytes
long,
- using a String instead of an io stream causes performances to degrade
to a total server freeze, as time is spent doing realloc of a buffer
always too short,
- Printing a 500 000 long string in the debug log is too verbose,
- Generating this string even when DBUG_PRINT is off is useless,
- Having code that potentially can affect the server behavior, used with
#ifdef / #endif is useful in some cases, but is also a bad practice.
After this change
=================
"Case Expressions" (both simple and searched) have been simplified to
not use LEX::when_list, which has been removed.
Considering all the issues affecting case statements, the grammar for these
has been totally re written.
The existing actions, used to generate "assembly" sp_inst* code, have been
preserved but moved in the new grammar, with the following changes:
a) Bison rules are no longer shared between "Simple" and "Searched" case
statements, because a stack instead of a flag is required to handle them.
Nested statements are handled naturally by the parser stack, which by
definition uses the correct rule in the correct context.
Nested statements of the opposite type (simple vs searched) works correctly.
The flag sp_head::IN_SIMPLE_CASE is no longer used.
This is a step towards resolution of WL#2999, which correctly identified
that temporary parsing flags do not belong to sp_head.
The code in the action is shared by mean of the case_stmt_action_xxx()
helpers.
b) The backpatch mechanism, used to resolve forward jumps in the generated
code, has been changed to:
- create a label for the instruction following 'END CASE',
- register each jump at the end of a "WHEN expr THEN stmt" in a *unique*
backpatch list associated with the 'END CASE' label
- resolve all the forward jumps for this label at once.
In addition, the code involving backpatch has been commented, so that a
reader can now understand by reading matching "Registering" and "Resolving"
comments how the forward jumps are resolved and what target they resolve to,
as this is far from evident when reading the code alone.
The implementation of sp_head::opt_mark() has been revised to avoid
recursive calls from jump instructions, and instead add the jump location
to the list of paths to explore during the flow analysis of the instruction
graph, with a call to sp_head::add_mark_lead().
In addition, the flow analysis will stop if an instruction has already
been marked as reachable, which the previous code failed to do in the
recursive case.
sp_head::opt_mark() is now private, to prevent new calls to this method from
being introduced.
The debug code present in sp_head::create() has been removed.
Considering that SHOW PROCEDURE CODE is also available in debug builds,
and can be used anytime regardless of the trace level, as opposed to
"CREATE PROCEDURE" time and only if the trace was on,
removing the code actually makes debugging easier (usable trace).
Tests have been written to cover the parser overflow (big CASE),
and to cover nested CASE statements.
2006-11-17 20:14:29 +01:00
|
|
|
/**
|
|
|
|
Optimize the code.
|
|
|
|
*/
|
2004-08-02 18:05:31 +02:00
|
|
|
void optimize();
|
Bug#19194 (Right recursion in parser for CASE causes excessive stack usage,
limitation)
Note to the reviewer
====================
Warning: reviewing this patch is somewhat involved.
Due to the nature of several issues all affecting the same area,
fixing separately each issue is not practical, since each fix can not be
implemented and tested independently.
In particular, the issues with
- rule recursion
- nested case statements
- forward jump resolution (backpatch list)
are tightly coupled (see below).
Definitions
===========
The expression
CASE expr
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Simple Case Expression".
The expression
CASE
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Searched Case Expression".
The statement
CASE expr
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Simple Case Statement".
The statement
CASE
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Searched Case Statement".
A "Left Recursive" rule is like
list:
element
| list element
;
A "Right Recursive" rule is like
list:
element
| element list
;
Left and right recursion produces the same language, the difference only
affects the *order* in which the text is parsed.
In a descendant parser (usually written manually), right recursion works
very well, and is typically implemented with a while loop.
In an ascendant parser (yacc/bison) left recursion works very well,
and is implemented naturally by the parser stack.
In both cases, using the wrong type or recursion is very bad and should be
avoided, as it causes technical issues with the parser implementation.
Before this change
==================
The "Simple Case Expression" and "Searched Case Expression" were both
implemented by the "when_list" and "when_list2" rules, which are left
recursive (ok).
These rules, however, used lex->when_list instead of using the parser stack,
which is more complex that necessary, and potentially dangerous because
of other rules using THD::reset_lex.
The "Simple Case Statement" and "Searched Case Statements" were implemented
by the "sp_case", "sp_whens" and in part by "sp_proc_stmt" rules.
Both cases were right recursive (bad).
The grammar involved was convoluted, and is assumed to be the results of
tweaks to get the code generation to work, but is not what someone would
naturally write.
In addition, using a common rule for both "Simple" and "Searched" case
statements was implemented with sp_head::m_flags |= IN_SIMPLE_CASE,
which is a flag and not a stack, and therefore does not take into account
*nested* case statements. This leads to incorrect generated code, and either
a server crash or an incorrect result.
With regards to the backpatch mechanism, a *different* backpatch list was
created for each jump from "WHEN expr THEN stmt" to "END CASE", which
relied on the grammar to be right recursive.
This is a mis-use of the backpatch list, since this list can resolve
multiple references to the same target at once.
The optimizer algorithm used to detect dead code in the "assembly" SQL
instructions, implemented by sp_head::opt_mark(uint ip), was recursive
in some cases (a conditional jump pointing forward to another conditional
jump).
In case of specially crafted code, like
- a long list of "IF expr THEN stmt END IF"
- a long CASE statement
this would actually cause a server crash with a stack overflow.
In general, having a stack that grows proportionally with user data (the
SQL code given by the client in a CREATE PROCEDURE) is to be avoided.
In debug builds only, creating a SP / SF / Trigger which had a significant
amount of code would spend --literally-- several minutes in sp_head::create,
because of the debug code involved with DBUG_PRINT("info", ("Code %s ...
There are several issues with this code:
- in a CASE with 5 000 WHEN, there are 15 000 instructions generated,
which create a sting representation of the code which is 500 000 bytes
long,
- using a String instead of an io stream causes performances to degrade
to a total server freeze, as time is spent doing realloc of a buffer
always too short,
- Printing a 500 000 long string in the debug log is too verbose,
- Generating this string even when DBUG_PRINT is off is useless,
- Having code that potentially can affect the server behavior, used with
#ifdef / #endif is useful in some cases, but is also a bad practice.
After this change
=================
"Case Expressions" (both simple and searched) have been simplified to
not use LEX::when_list, which has been removed.
Considering all the issues affecting case statements, the grammar for these
has been totally re written.
The existing actions, used to generate "assembly" sp_inst* code, have been
preserved but moved in the new grammar, with the following changes:
a) Bison rules are no longer shared between "Simple" and "Searched" case
statements, because a stack instead of a flag is required to handle them.
Nested statements are handled naturally by the parser stack, which by
definition uses the correct rule in the correct context.
Nested statements of the opposite type (simple vs searched) works correctly.
The flag sp_head::IN_SIMPLE_CASE is no longer used.
This is a step towards resolution of WL#2999, which correctly identified
that temporary parsing flags do not belong to sp_head.
The code in the action is shared by mean of the case_stmt_action_xxx()
helpers.
b) The backpatch mechanism, used to resolve forward jumps in the generated
code, has been changed to:
- create a label for the instruction following 'END CASE',
- register each jump at the end of a "WHEN expr THEN stmt" in a *unique*
backpatch list associated with the 'END CASE' label
- resolve all the forward jumps for this label at once.
In addition, the code involving backpatch has been commented, so that a
reader can now understand by reading matching "Registering" and "Resolving"
comments how the forward jumps are resolved and what target they resolve to,
as this is far from evident when reading the code alone.
The implementation of sp_head::opt_mark() has been revised to avoid
recursive calls from jump instructions, and instead add the jump location
to the list of paths to explore during the flow analysis of the instruction
graph, with a call to sp_head::add_mark_lead().
In addition, the flow analysis will stop if an instruction has already
been marked as reachable, which the previous code failed to do in the
recursive case.
sp_head::opt_mark() is now private, to prevent new calls to this method from
being introduced.
The debug code present in sp_head::create() has been removed.
Considering that SHOW PROCEDURE CODE is also available in debug builds,
and can be used anytime regardless of the trace level, as opposed to
"CREATE PROCEDURE" time and only if the trace was on,
removing the code actually makes debugging easier (usable trace).
Tests have been written to cover the parser overflow (big CASE),
and to cover nested CASE statements.
2006-11-17 20:14:29 +01:00
|
|
|
|
|
|
|
/**
|
|
|
|
Helper used during flow analysis during code optimization.
|
|
|
|
See the implementation of <code>opt_mark()</code>.
|
|
|
|
@param ip the instruction to add to the leads list
|
|
|
|
@param leads the list of remaining paths to explore in the graph that
|
|
|
|
represents the code, during flow analysis.
|
|
|
|
*/
|
|
|
|
void add_mark_lead(uint ip, List<sp_instr> *leads);
|
2004-08-02 18:05:31 +02:00
|
|
|
|
2006-01-05 23:47:49 +01:00
|
|
|
void recursion_level_error(THD *thd);
|
2005-11-23 00:11:19 +01:00
|
|
|
|
2004-08-02 18:05:31 +02:00
|
|
|
inline sp_instr *
|
|
|
|
get_instr(uint i)
|
|
|
|
{
|
|
|
|
sp_instr *ip;
|
|
|
|
|
|
|
|
if (i < m_instr.elements)
|
|
|
|
get_dynamic(&m_instr, (gptr)&ip, i);
|
|
|
|
else
|
|
|
|
ip= NULL;
|
|
|
|
return ip;
|
|
|
|
}
|
2003-05-06 18:09:20 +02:00
|
|
|
|
2005-03-04 14:35:28 +01:00
|
|
|
/* Add tables used by routine to the table list. */
|
|
|
|
bool add_used_tables_to_table_list(THD *thd,
|
2005-12-07 10:27:17 +01:00
|
|
|
TABLE_LIST ***query_tables_last_ptr,
|
|
|
|
TABLE_LIST *belong_to_view);
|
2005-03-04 14:35:28 +01:00
|
|
|
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
/*
|
|
|
|
Check if this stored routine contains statements disallowed
|
|
|
|
in a stored function or trigger, and set an appropriate error message
|
|
|
|
if this is the case.
|
|
|
|
*/
|
|
|
|
bool is_not_allowed_in_function(const char *where)
|
|
|
|
{
|
|
|
|
if (m_flags & CONTAINS_DYNAMIC_SQL)
|
|
|
|
my_error(ER_STMT_NOT_ALLOWED_IN_SF_OR_TRG, MYF(0), "Dynamic SQL");
|
|
|
|
else if (m_flags & MULTI_RESULTS)
|
|
|
|
my_error(ER_SP_NO_RETSET, MYF(0), where);
|
2005-09-13 17:16:12 +02:00
|
|
|
else if (m_flags & HAS_SET_AUTOCOMMIT_STMT)
|
|
|
|
my_error(ER_SP_CANT_SET_AUTOCOMMIT, MYF(0));
|
2006-08-25 15:51:29 +02:00
|
|
|
else if (m_flags & HAS_COMMIT_OR_ROLLBACK)
|
2005-11-16 13:09:06 +01:00
|
|
|
my_error(ER_COMMIT_NOT_ALLOWED_IN_SF_OR_TRG, MYF(0));
|
2006-08-25 15:51:29 +02:00
|
|
|
else if (m_flags & HAS_SQLCOM_RESET)
|
|
|
|
my_error(ER_STMT_NOT_ALLOWED_IN_SF_OR_TRG, MYF(0), "RESET");
|
|
|
|
else if (m_flags & HAS_SQLCOM_FLUSH)
|
|
|
|
my_error(ER_STMT_NOT_ALLOWED_IN_SF_OR_TRG, MYF(0), "FLUSH");
|
|
|
|
|
2005-09-14 10:54:02 +02:00
|
|
|
return test(m_flags &
|
2006-08-25 15:51:29 +02:00
|
|
|
(CONTAINS_DYNAMIC_SQL|MULTI_RESULTS|HAS_SET_AUTOCOMMIT_STMT|
|
|
|
|
HAS_COMMIT_OR_ROLLBACK|HAS_SQLCOM_RESET|HAS_SQLCOM_FLUSH));
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
}
|
2005-11-17 11:11:48 +01:00
|
|
|
|
|
|
|
#ifndef DBUG_OFF
|
|
|
|
int show_routine_code(THD *thd);
|
|
|
|
#endif
|
|
|
|
|
* Mixed replication mode * :
1) Fix for BUG#19630 "stored function inserting into two auto_increment breaks
statement-based binlog":
a stored function inserting into two such tables may fail to replicate
(inserting wrong data in the slave's copy of the second table) if the slave's
second table had an internal auto_increment counter different from master's.
Because the auto_increment value autogenerated by master for the 2nd table
does not go into binlog, only the first does, so the slave lacks information.
To fix this, if running in mixed binlogging mode, if the stored function or
trigger plans to update two different tables both having auto_increment
columns, we switch to row-based for the whole function.
We don't have a simple solution for statement-based binlogging mode, there
the bug remains and will be documented as a known problem.
Re-enabling rpl_switch_stm_row_mixed.
2) Fix for BUG#20630 "Mixed binlogging mode does not work with stored
functions, triggers, views", which was a documented limitation (in mixed
mode, we didn't detect that a stored function's execution needed row-based
binlogging (due to some UUID() call for example); same for
triggers, same for views (a view created from a SELECT UUID(), and doing
INSERT INTO sometable SELECT theview; would not replicate row-based).
This is implemented by, after parsing a routine's body, remembering in sp_head
that this routine needs row-based binlogging. Then when this routine is used,
the caller is marked to require row-based binlogging too.
Same for views: when we parse a view and detect that its SELECT needs
row-based binary logging, we mark the calling LEX as such.
3) Fix for BUG#20499 "mixed mode with temporary table breaks binlog":
a temporary table containing e.g. UUID has its changes not binlogged,
so any query updating a permanent table with data from the temporary table
will run wrongly on slave. Solution: in mixed mode we don't switch back
from row-based to statement-based when there exists temporary tables.
4) Attempt to test mysqlbinlog on a binlog generated by mysqlbinlog;
impossible due to BUG#11312 and BUG#20329, but test is in place for when
they are fixed.
2006-07-09 17:00:47 +02:00
|
|
|
/*
|
|
|
|
This method is intended for attributes of a routine which need
|
|
|
|
to propagate upwards to the LEX of the caller (when a property of a
|
|
|
|
sp_head needs to "taint" the caller).
|
|
|
|
*/
|
|
|
|
void propagate_attributes(LEX *lex)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
If this routine needs row-based binary logging, the entire top statement
|
|
|
|
too (we cannot switch from statement-based to row-based only for this
|
|
|
|
routine, as in statement-based the top-statement may be binlogged and
|
|
|
|
the substatements not).
|
|
|
|
*/
|
|
|
|
if (m_flags & BINLOG_ROW_BASED_IF_MIXED)
|
|
|
|
lex->binlog_row_based_if_mixed= TRUE;
|
|
|
|
}
|
|
|
|
|
2005-11-17 11:11:48 +01:00
|
|
|
|
Simplistic, experimental framework for Stored Procedures (SPs).
Implements creation and dropping of PROCEDUREs, IN, OUT, and INOUT parameters,
single-statement procedures, rudimentary multi-statement (begin-end) prodedures
(when the client can handle it), and local variables.
Missing most of the embedded SQL language, all attributes, FUNCTIONs, error handling,
reparses procedures at each call (no caching), etc, etc.
Certainly buggy too, but procedures can actually be created and called....
2002-12-08 19:59:22 +01:00
|
|
|
private:
|
|
|
|
|
2004-11-09 02:58:44 +01:00
|
|
|
MEM_ROOT *m_thd_root; // Temp. store for thd's mem_root
|
2003-06-29 18:15:17 +02:00
|
|
|
THD *m_thd; // Set if we have reset mem_root
|
2003-07-07 14:55:10 +02:00
|
|
|
|
2003-03-02 19:17:41 +01:00
|
|
|
sp_pcontext *m_pcont; // Parse context
|
2003-06-29 18:15:17 +02:00
|
|
|
List<LEX> m_lex; // Temp. store for the other lex
|
Simplistic, experimental framework for Stored Procedures (SPs).
Implements creation and dropping of PROCEDUREs, IN, OUT, and INOUT parameters,
single-statement procedures, rudimentary multi-statement (begin-end) prodedures
(when the client can handle it), and local variables.
Missing most of the embedded SQL language, all attributes, FUNCTIONs, error handling,
reparses procedures at each call (no caching), etc, etc.
Certainly buggy too, but procedures can actually be created and called....
2002-12-08 19:59:22 +01:00
|
|
|
DYNAMIC_ARRAY m_instr; // The "instructions"
|
2002-12-16 15:40:44 +01:00
|
|
|
typedef struct
|
|
|
|
{
|
|
|
|
struct sp_label *lab;
|
|
|
|
sp_instr *instr;
|
|
|
|
} bp_t;
|
2003-02-21 17:37:05 +01:00
|
|
|
List<bp_t> m_backpatch; // Instructions needing backpatching
|
2005-11-04 15:37:39 +01:00
|
|
|
/*
|
2006-01-26 17:26:25 +01:00
|
|
|
We need a special list for backpatching of instructions with a continue
|
2005-11-04 15:37:39 +01:00
|
|
|
destination (in the case of a continue handler catching an error in
|
|
|
|
the test), since it would otherwise interfere with the normal backpatch
|
2006-01-26 17:26:25 +01:00
|
|
|
mechanism - e.g. jump_if_not instructions have two different destinations
|
2005-11-04 15:37:39 +01:00
|
|
|
which are to be patched differently.
|
|
|
|
Since these occur in a more restricted way (always the same "level" in
|
|
|
|
the code), we don't need the label.
|
|
|
|
*/
|
2006-01-26 17:26:25 +01:00
|
|
|
List<sp_instr_opt_meta> m_cont_backpatch;
|
2005-11-04 15:37:39 +01:00
|
|
|
uint m_cont_level; // The current cont. backpatch level
|
|
|
|
|
2005-03-04 14:35:28 +01:00
|
|
|
/*
|
|
|
|
Multi-set representing optimized list of tables to be locked by this
|
|
|
|
routine. Does not include tables which are used by invoked routines.
|
2005-07-30 10:19:57 +02:00
|
|
|
|
|
|
|
Note: for prelocking-free SPs this multiset is constructed too.
|
|
|
|
We do so because the same instance of sp_head may be called both
|
|
|
|
in prelocked mode and in non-prelocked mode.
|
2005-03-04 14:35:28 +01:00
|
|
|
*/
|
|
|
|
HASH m_sptabs;
|
Simplistic, experimental framework for Stored Procedures (SPs).
Implements creation and dropping of PROCEDUREs, IN, OUT, and INOUT parameters,
single-statement procedures, rudimentary multi-statement (begin-end) prodedures
(when the client can handle it), and local variables.
Missing most of the embedded SQL language, all attributes, FUNCTIONs, error handling,
reparses procedures at each call (no caching), etc, etc.
Certainly buggy too, but procedures can actually be created and called....
2002-12-08 19:59:22 +01:00
|
|
|
|
2005-12-07 15:01:17 +01:00
|
|
|
bool
|
2003-02-26 19:22:29 +01:00
|
|
|
execute(THD *thd);
|
|
|
|
|
Bug#19194 (Right recursion in parser for CASE causes excessive stack usage,
limitation)
Note to the reviewer
====================
Warning: reviewing this patch is somewhat involved.
Due to the nature of several issues all affecting the same area,
fixing separately each issue is not practical, since each fix can not be
implemented and tested independently.
In particular, the issues with
- rule recursion
- nested case statements
- forward jump resolution (backpatch list)
are tightly coupled (see below).
Definitions
===========
The expression
CASE expr
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Simple Case Expression".
The expression
CASE
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Searched Case Expression".
The statement
CASE expr
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Simple Case Statement".
The statement
CASE
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Searched Case Statement".
A "Left Recursive" rule is like
list:
element
| list element
;
A "Right Recursive" rule is like
list:
element
| element list
;
Left and right recursion produces the same language, the difference only
affects the *order* in which the text is parsed.
In a descendant parser (usually written manually), right recursion works
very well, and is typically implemented with a while loop.
In an ascendant parser (yacc/bison) left recursion works very well,
and is implemented naturally by the parser stack.
In both cases, using the wrong type or recursion is very bad and should be
avoided, as it causes technical issues with the parser implementation.
Before this change
==================
The "Simple Case Expression" and "Searched Case Expression" were both
implemented by the "when_list" and "when_list2" rules, which are left
recursive (ok).
These rules, however, used lex->when_list instead of using the parser stack,
which is more complex that necessary, and potentially dangerous because
of other rules using THD::reset_lex.
The "Simple Case Statement" and "Searched Case Statements" were implemented
by the "sp_case", "sp_whens" and in part by "sp_proc_stmt" rules.
Both cases were right recursive (bad).
The grammar involved was convoluted, and is assumed to be the results of
tweaks to get the code generation to work, but is not what someone would
naturally write.
In addition, using a common rule for both "Simple" and "Searched" case
statements was implemented with sp_head::m_flags |= IN_SIMPLE_CASE,
which is a flag and not a stack, and therefore does not take into account
*nested* case statements. This leads to incorrect generated code, and either
a server crash or an incorrect result.
With regards to the backpatch mechanism, a *different* backpatch list was
created for each jump from "WHEN expr THEN stmt" to "END CASE", which
relied on the grammar to be right recursive.
This is a mis-use of the backpatch list, since this list can resolve
multiple references to the same target at once.
The optimizer algorithm used to detect dead code in the "assembly" SQL
instructions, implemented by sp_head::opt_mark(uint ip), was recursive
in some cases (a conditional jump pointing forward to another conditional
jump).
In case of specially crafted code, like
- a long list of "IF expr THEN stmt END IF"
- a long CASE statement
this would actually cause a server crash with a stack overflow.
In general, having a stack that grows proportionally with user data (the
SQL code given by the client in a CREATE PROCEDURE) is to be avoided.
In debug builds only, creating a SP / SF / Trigger which had a significant
amount of code would spend --literally-- several minutes in sp_head::create,
because of the debug code involved with DBUG_PRINT("info", ("Code %s ...
There are several issues with this code:
- in a CASE with 5 000 WHEN, there are 15 000 instructions generated,
which create a sting representation of the code which is 500 000 bytes
long,
- using a String instead of an io stream causes performances to degrade
to a total server freeze, as time is spent doing realloc of a buffer
always too short,
- Printing a 500 000 long string in the debug log is too verbose,
- Generating this string even when DBUG_PRINT is off is useless,
- Having code that potentially can affect the server behavior, used with
#ifdef / #endif is useful in some cases, but is also a bad practice.
After this change
=================
"Case Expressions" (both simple and searched) have been simplified to
not use LEX::when_list, which has been removed.
Considering all the issues affecting case statements, the grammar for these
has been totally re written.
The existing actions, used to generate "assembly" sp_inst* code, have been
preserved but moved in the new grammar, with the following changes:
a) Bison rules are no longer shared between "Simple" and "Searched" case
statements, because a stack instead of a flag is required to handle them.
Nested statements are handled naturally by the parser stack, which by
definition uses the correct rule in the correct context.
Nested statements of the opposite type (simple vs searched) works correctly.
The flag sp_head::IN_SIMPLE_CASE is no longer used.
This is a step towards resolution of WL#2999, which correctly identified
that temporary parsing flags do not belong to sp_head.
The code in the action is shared by mean of the case_stmt_action_xxx()
helpers.
b) The backpatch mechanism, used to resolve forward jumps in the generated
code, has been changed to:
- create a label for the instruction following 'END CASE',
- register each jump at the end of a "WHEN expr THEN stmt" in a *unique*
backpatch list associated with the 'END CASE' label
- resolve all the forward jumps for this label at once.
In addition, the code involving backpatch has been commented, so that a
reader can now understand by reading matching "Registering" and "Resolving"
comments how the forward jumps are resolved and what target they resolve to,
as this is far from evident when reading the code alone.
The implementation of sp_head::opt_mark() has been revised to avoid
recursive calls from jump instructions, and instead add the jump location
to the list of paths to explore during the flow analysis of the instruction
graph, with a call to sp_head::add_mark_lead().
In addition, the flow analysis will stop if an instruction has already
been marked as reachable, which the previous code failed to do in the
recursive case.
sp_head::opt_mark() is now private, to prevent new calls to this method from
being introduced.
The debug code present in sp_head::create() has been removed.
Considering that SHOW PROCEDURE CODE is also available in debug builds,
and can be used anytime regardless of the trace level, as opposed to
"CREATE PROCEDURE" time and only if the trace was on,
removing the code actually makes debugging easier (usable trace).
Tests have been written to cover the parser overflow (big CASE),
and to cover nested CASE statements.
2006-11-17 20:14:29 +01:00
|
|
|
/**
|
|
|
|
Perform a forward flow analysis in the generated code.
|
|
|
|
Mark reachable instructions, for the optimizer.
|
|
|
|
*/
|
|
|
|
void opt_mark();
|
|
|
|
|
2005-03-04 14:35:28 +01:00
|
|
|
/*
|
|
|
|
Merge the list of tables used by query into the multi-set of tables used
|
|
|
|
by routine.
|
|
|
|
*/
|
|
|
|
bool merge_table_list(THD *thd, TABLE_LIST *table, LEX *lex_for_tmp_check);
|
Simplistic, experimental framework for Stored Procedures (SPs).
Implements creation and dropping of PROCEDUREs, IN, OUT, and INOUT parameters,
single-statement procedures, rudimentary multi-statement (begin-end) prodedures
(when the client can handle it), and local variables.
Missing most of the embedded SQL language, all attributes, FUNCTIONs, error handling,
reparses procedures at each call (no caching), etc, etc.
Certainly buggy too, but procedures can actually be created and called....
2002-12-08 19:59:22 +01:00
|
|
|
}; // class sp_head : public Sql_alloc
|
|
|
|
|
|
|
|
|
2002-12-11 14:24:29 +01:00
|
|
|
//
|
|
|
|
// "Instructions"...
|
|
|
|
//
|
|
|
|
|
2005-06-23 18:22:08 +02:00
|
|
|
class sp_instr :public Query_arena, public Sql_alloc
|
Simplistic, experimental framework for Stored Procedures (SPs).
Implements creation and dropping of PROCEDUREs, IN, OUT, and INOUT parameters,
single-statement procedures, rudimentary multi-statement (begin-end) prodedures
(when the client can handle it), and local variables.
Missing most of the embedded SQL language, all attributes, FUNCTIONs, error handling,
reparses procedures at each call (no caching), etc, etc.
Certainly buggy too, but procedures can actually be created and called....
2002-12-08 19:59:22 +01:00
|
|
|
{
|
|
|
|
sp_instr(const sp_instr &); /* Prevent use of these */
|
|
|
|
void operator=(sp_instr &);
|
|
|
|
|
|
|
|
public:
|
|
|
|
|
2004-08-02 18:05:31 +02:00
|
|
|
uint marked;
|
|
|
|
uint m_ip; // My index
|
2004-08-26 12:54:30 +02:00
|
|
|
sp_pcontext *m_ctx; // My parse context
|
2004-05-26 13:28:35 +02:00
|
|
|
|
Simplistic, experimental framework for Stored Procedures (SPs).
Implements creation and dropping of PROCEDUREs, IN, OUT, and INOUT parameters,
single-statement procedures, rudimentary multi-statement (begin-end) prodedures
(when the client can handle it), and local variables.
Missing most of the embedded SQL language, all attributes, FUNCTIONs, error handling,
reparses procedures at each call (no caching), etc, etc.
Certainly buggy too, but procedures can actually be created and called....
2002-12-08 19:59:22 +01:00
|
|
|
// Should give each a name or type code for debugging purposes?
|
2004-08-26 12:54:30 +02:00
|
|
|
sp_instr(uint ip, sp_pcontext *ctx)
|
2005-06-23 18:22:08 +02:00
|
|
|
:Query_arena(0, INITIALIZED_FOR_SP), marked(0), m_ip(ip), m_ctx(ctx)
|
Simplistic, experimental framework for Stored Procedures (SPs).
Implements creation and dropping of PROCEDUREs, IN, OUT, and INOUT parameters,
single-statement procedures, rudimentary multi-statement (begin-end) prodedures
(when the client can handle it), and local variables.
Missing most of the embedded SQL language, all attributes, FUNCTIONs, error handling,
reparses procedures at each call (no caching), etc, etc.
Certainly buggy too, but procedures can actually be created and called....
2002-12-08 19:59:22 +01:00
|
|
|
{}
|
|
|
|
|
|
|
|
virtual ~sp_instr()
|
2005-06-23 18:22:08 +02:00
|
|
|
{ free_items(); }
|
Simplistic, experimental framework for Stored Procedures (SPs).
Implements creation and dropping of PROCEDUREs, IN, OUT, and INOUT parameters,
single-statement procedures, rudimentary multi-statement (begin-end) prodedures
(when the client can handle it), and local variables.
Missing most of the embedded SQL language, all attributes, FUNCTIONs, error handling,
reparses procedures at each call (no caching), etc, etc.
Certainly buggy too, but procedures can actually be created and called....
2002-12-08 19:59:22 +01:00
|
|
|
|
2005-08-25 15:34:34 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
Execute this instruction
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
execute()
|
|
|
|
thd Thread handle
|
|
|
|
nextp OUT index of the next instruction to execute. (For most
|
|
|
|
instructions this will be the instruction following this
|
2007-03-07 17:53:46 +01:00
|
|
|
one). Note that this parameter is undefined in case of
|
|
|
|
errors, use get_cont_dest() to find the continuation
|
|
|
|
instruction for CONTINUE error handlers.
|
|
|
|
|
|
|
|
RETURN
|
|
|
|
0 on success,
|
|
|
|
other if some error occurred
|
2005-08-25 15:34:34 +02:00
|
|
|
*/
|
2007-03-07 17:53:46 +01:00
|
|
|
|
2004-03-29 11:16:45 +02:00
|
|
|
virtual int execute(THD *thd, uint *nextp) = 0;
|
|
|
|
|
Bug#8407 (Stored functions/triggers ignore exception handler)
Bug 18914 (Calling certain SPs from triggers fail)
Bug 20713 (Functions will not not continue for SQLSTATE VALUE '42S02')
Bug 21825 (Incorrect message error deleting records in a table with a
trigger for inserting)
Bug 22580 (DROP TABLE in nested stored procedure causes strange dependency
error)
Bug 25345 (Cursors from Functions)
This fix resolves a long standing issue originally reported with bug 8407,
which affect the behavior of Stored Procedures, Stored Functions and Trigger
in many different ways, causing symptoms reported by all the bugs listed.
In all cases, the root cause of the problem traces back to 8407 and how the
server locks tables involved with sub statements.
Prior to this fix, the implementation of stored routines would:
- compute the transitive closure of all the tables referenced by a top level
statement
- open and lock all the tables involved
- execute the top level statement
"transitive closure of tables" means collecting:
- all the tables,
- all the stored functions,
- all the views,
- all the table triggers
- all the stored procedures
involved, and recursively inspect these objects definition to find more
references to more objects, until the list of every object referenced does
not grow any more.
This mechanism is known as "pre-locking" tables before execution.
The motivation for locking all the tables (possibly) used at once is to
prevent dead locks.
One problem with this approach is that, if the execution path the code
really takes during runtime does not use a given table, and if the table is
missing, the server would not execute the statement.
This in particular has a major impact on triggers, since a missing table
referenced by an update/delete trigger would prevent an insert trigger to run.
Another problem is that stored routines might define SQL exception handlers
to deal with missing tables, but the server implementation would never give
user code a chance to execute this logic, since the routine is never
executed when a missing table cause the pre-locking code to fail.
With this fix, the internal implementation of the pre-locking code has been
relaxed of some constraints, so that failure to open a table does not
necessarily prevent execution of a stored routine.
In particular, the pre-locking mechanism is now behaving as follows:
1) the first step, to compute the transitive closure of all the tables
possibly referenced by a statement, is unchanged.
2) the next step, which is to open all the tables involved, only attempts
to open the tables added by the pre-locking code, but silently fails without
reporting any error or invoking any exception handler is the table is not
present. This is achieved by trapping internal errors with
Prelock_error_handler
3) the locking step only locks tables that were successfully opened.
4) when executing sub statements, the list of tables used by each statements
is evaluated as before. The tables needed by the sub statement are expected
to be already opened and locked. Statement referencing tables that were not
opened in step 2) will fail to find the table in the open list, and only at
this point will execution of the user code fail.
5) when a runtime exception is raised at 4), the instruction continuation
destination (the next instruction to execute in case of SQL continue
handlers) is evaluated.
This is achieved with sp_instr::exec_open_and_lock_tables()
6) if a user exception handler is present in the stored routine, that
handler is invoked as usual, so that ER_NO_SUCH_TABLE exceptions can be
trapped by stored routines. If no handler exists, then the runtime execution
will fail as expected.
With all these changes, a side effect is that view security is impacted, in
two different ways.
First, a view defined as "select stored_function()", where the stored
function references a table that may not exist, is considered valid.
The rationale is that, because the stored function might trap exceptions
during execution and still return a valid result, there is no way to decide
when the view is created if a missing table really cause the view to be invalid.
Secondly, testing for existence of tables is now done later during
execution. View security, which consist of trapping errors and return a
generic ER_VIEW_INVALID (to prevent disclosing information) was only
implemented at very specific phases covering *opening* tables, but not
covering the runtime execution. Because of this existing limitation,
errors that were previously trapped and converted into ER_VIEW_INVALID are
not trapped, causing table names to be reported to the user.
This change is exposing an existing problem, which is independent and will
be resolved separately.
2007-03-06 03:42:07 +01:00
|
|
|
/**
|
|
|
|
Execute <code>open_and_lock_tables()</code> for this statement.
|
|
|
|
Open and lock the tables used by this statement, as a pre-requisite
|
|
|
|
to execute the core logic of this instruction with
|
|
|
|
<code>exec_core()</code>.
|
|
|
|
@param thd the current thread
|
|
|
|
@param tables the list of tables to open and lock
|
|
|
|
@return zero on success, non zero on failure.
|
|
|
|
*/
|
2007-03-07 17:53:46 +01:00
|
|
|
int exec_open_and_lock_tables(THD *thd, TABLE_LIST *tables);
|
Bug#8407 (Stored functions/triggers ignore exception handler)
Bug 18914 (Calling certain SPs from triggers fail)
Bug 20713 (Functions will not not continue for SQLSTATE VALUE '42S02')
Bug 21825 (Incorrect message error deleting records in a table with a
trigger for inserting)
Bug 22580 (DROP TABLE in nested stored procedure causes strange dependency
error)
Bug 25345 (Cursors from Functions)
This fix resolves a long standing issue originally reported with bug 8407,
which affect the behavior of Stored Procedures, Stored Functions and Trigger
in many different ways, causing symptoms reported by all the bugs listed.
In all cases, the root cause of the problem traces back to 8407 and how the
server locks tables involved with sub statements.
Prior to this fix, the implementation of stored routines would:
- compute the transitive closure of all the tables referenced by a top level
statement
- open and lock all the tables involved
- execute the top level statement
"transitive closure of tables" means collecting:
- all the tables,
- all the stored functions,
- all the views,
- all the table triggers
- all the stored procedures
involved, and recursively inspect these objects definition to find more
references to more objects, until the list of every object referenced does
not grow any more.
This mechanism is known as "pre-locking" tables before execution.
The motivation for locking all the tables (possibly) used at once is to
prevent dead locks.
One problem with this approach is that, if the execution path the code
really takes during runtime does not use a given table, and if the table is
missing, the server would not execute the statement.
This in particular has a major impact on triggers, since a missing table
referenced by an update/delete trigger would prevent an insert trigger to run.
Another problem is that stored routines might define SQL exception handlers
to deal with missing tables, but the server implementation would never give
user code a chance to execute this logic, since the routine is never
executed when a missing table cause the pre-locking code to fail.
With this fix, the internal implementation of the pre-locking code has been
relaxed of some constraints, so that failure to open a table does not
necessarily prevent execution of a stored routine.
In particular, the pre-locking mechanism is now behaving as follows:
1) the first step, to compute the transitive closure of all the tables
possibly referenced by a statement, is unchanged.
2) the next step, which is to open all the tables involved, only attempts
to open the tables added by the pre-locking code, but silently fails without
reporting any error or invoking any exception handler is the table is not
present. This is achieved by trapping internal errors with
Prelock_error_handler
3) the locking step only locks tables that were successfully opened.
4) when executing sub statements, the list of tables used by each statements
is evaluated as before. The tables needed by the sub statement are expected
to be already opened and locked. Statement referencing tables that were not
opened in step 2) will fail to find the table in the open list, and only at
this point will execution of the user code fail.
5) when a runtime exception is raised at 4), the instruction continuation
destination (the next instruction to execute in case of SQL continue
handlers) is evaluated.
This is achieved with sp_instr::exec_open_and_lock_tables()
6) if a user exception handler is present in the stored routine, that
handler is invoked as usual, so that ER_NO_SUCH_TABLE exceptions can be
trapped by stored routines. If no handler exists, then the runtime execution
will fail as expected.
With all these changes, a side effect is that view security is impacted, in
two different ways.
First, a view defined as "select stored_function()", where the stored
function references a table that may not exist, is considered valid.
The rationale is that, because the stored function might trap exceptions
during execution and still return a valid result, there is no way to decide
when the view is created if a missing table really cause the view to be invalid.
Secondly, testing for existence of tables is now done later during
execution. View security, which consist of trapping errors and return a
generic ER_VIEW_INVALID (to prevent disclosing information) was only
implemented at very specific phases covering *opening* tables, but not
covering the runtime execution. Because of this existing limitation,
errors that were previously trapped and converted into ER_VIEW_INVALID are
not trapped, causing table names to be reported to the user.
This change is exposing an existing problem, which is independent and will
be resolved separately.
2007-03-06 03:42:07 +01:00
|
|
|
|
|
|
|
/**
|
|
|
|
Get the continuation destination of this instruction.
|
2007-03-07 17:53:46 +01:00
|
|
|
@return the continuation destination
|
Bug#8407 (Stored functions/triggers ignore exception handler)
Bug 18914 (Calling certain SPs from triggers fail)
Bug 20713 (Functions will not not continue for SQLSTATE VALUE '42S02')
Bug 21825 (Incorrect message error deleting records in a table with a
trigger for inserting)
Bug 22580 (DROP TABLE in nested stored procedure causes strange dependency
error)
Bug 25345 (Cursors from Functions)
This fix resolves a long standing issue originally reported with bug 8407,
which affect the behavior of Stored Procedures, Stored Functions and Trigger
in many different ways, causing symptoms reported by all the bugs listed.
In all cases, the root cause of the problem traces back to 8407 and how the
server locks tables involved with sub statements.
Prior to this fix, the implementation of stored routines would:
- compute the transitive closure of all the tables referenced by a top level
statement
- open and lock all the tables involved
- execute the top level statement
"transitive closure of tables" means collecting:
- all the tables,
- all the stored functions,
- all the views,
- all the table triggers
- all the stored procedures
involved, and recursively inspect these objects definition to find more
references to more objects, until the list of every object referenced does
not grow any more.
This mechanism is known as "pre-locking" tables before execution.
The motivation for locking all the tables (possibly) used at once is to
prevent dead locks.
One problem with this approach is that, if the execution path the code
really takes during runtime does not use a given table, and if the table is
missing, the server would not execute the statement.
This in particular has a major impact on triggers, since a missing table
referenced by an update/delete trigger would prevent an insert trigger to run.
Another problem is that stored routines might define SQL exception handlers
to deal with missing tables, but the server implementation would never give
user code a chance to execute this logic, since the routine is never
executed when a missing table cause the pre-locking code to fail.
With this fix, the internal implementation of the pre-locking code has been
relaxed of some constraints, so that failure to open a table does not
necessarily prevent execution of a stored routine.
In particular, the pre-locking mechanism is now behaving as follows:
1) the first step, to compute the transitive closure of all the tables
possibly referenced by a statement, is unchanged.
2) the next step, which is to open all the tables involved, only attempts
to open the tables added by the pre-locking code, but silently fails without
reporting any error or invoking any exception handler is the table is not
present. This is achieved by trapping internal errors with
Prelock_error_handler
3) the locking step only locks tables that were successfully opened.
4) when executing sub statements, the list of tables used by each statements
is evaluated as before. The tables needed by the sub statement are expected
to be already opened and locked. Statement referencing tables that were not
opened in step 2) will fail to find the table in the open list, and only at
this point will execution of the user code fail.
5) when a runtime exception is raised at 4), the instruction continuation
destination (the next instruction to execute in case of SQL continue
handlers) is evaluated.
This is achieved with sp_instr::exec_open_and_lock_tables()
6) if a user exception handler is present in the stored routine, that
handler is invoked as usual, so that ER_NO_SUCH_TABLE exceptions can be
trapped by stored routines. If no handler exists, then the runtime execution
will fail as expected.
With all these changes, a side effect is that view security is impacted, in
two different ways.
First, a view defined as "select stored_function()", where the stored
function references a table that may not exist, is considered valid.
The rationale is that, because the stored function might trap exceptions
during execution and still return a valid result, there is no way to decide
when the view is created if a missing table really cause the view to be invalid.
Secondly, testing for existence of tables is now done later during
execution. View security, which consist of trapping errors and return a
generic ER_VIEW_INVALID (to prevent disclosing information) was only
implemented at very specific phases covering *opening* tables, but not
covering the runtime execution. Because of this existing limitation,
errors that were previously trapped and converted into ER_VIEW_INVALID are
not trapped, causing table names to be reported to the user.
This change is exposing an existing problem, which is independent and will
be resolved separately.
2007-03-06 03:42:07 +01:00
|
|
|
*/
|
2007-03-07 17:53:46 +01:00
|
|
|
virtual uint get_cont_dest();
|
Bug#8407 (Stored functions/triggers ignore exception handler)
Bug 18914 (Calling certain SPs from triggers fail)
Bug 20713 (Functions will not not continue for SQLSTATE VALUE '42S02')
Bug 21825 (Incorrect message error deleting records in a table with a
trigger for inserting)
Bug 22580 (DROP TABLE in nested stored procedure causes strange dependency
error)
Bug 25345 (Cursors from Functions)
This fix resolves a long standing issue originally reported with bug 8407,
which affect the behavior of Stored Procedures, Stored Functions and Trigger
in many different ways, causing symptoms reported by all the bugs listed.
In all cases, the root cause of the problem traces back to 8407 and how the
server locks tables involved with sub statements.
Prior to this fix, the implementation of stored routines would:
- compute the transitive closure of all the tables referenced by a top level
statement
- open and lock all the tables involved
- execute the top level statement
"transitive closure of tables" means collecting:
- all the tables,
- all the stored functions,
- all the views,
- all the table triggers
- all the stored procedures
involved, and recursively inspect these objects definition to find more
references to more objects, until the list of every object referenced does
not grow any more.
This mechanism is known as "pre-locking" tables before execution.
The motivation for locking all the tables (possibly) used at once is to
prevent dead locks.
One problem with this approach is that, if the execution path the code
really takes during runtime does not use a given table, and if the table is
missing, the server would not execute the statement.
This in particular has a major impact on triggers, since a missing table
referenced by an update/delete trigger would prevent an insert trigger to run.
Another problem is that stored routines might define SQL exception handlers
to deal with missing tables, but the server implementation would never give
user code a chance to execute this logic, since the routine is never
executed when a missing table cause the pre-locking code to fail.
With this fix, the internal implementation of the pre-locking code has been
relaxed of some constraints, so that failure to open a table does not
necessarily prevent execution of a stored routine.
In particular, the pre-locking mechanism is now behaving as follows:
1) the first step, to compute the transitive closure of all the tables
possibly referenced by a statement, is unchanged.
2) the next step, which is to open all the tables involved, only attempts
to open the tables added by the pre-locking code, but silently fails without
reporting any error or invoking any exception handler is the table is not
present. This is achieved by trapping internal errors with
Prelock_error_handler
3) the locking step only locks tables that were successfully opened.
4) when executing sub statements, the list of tables used by each statements
is evaluated as before. The tables needed by the sub statement are expected
to be already opened and locked. Statement referencing tables that were not
opened in step 2) will fail to find the table in the open list, and only at
this point will execution of the user code fail.
5) when a runtime exception is raised at 4), the instruction continuation
destination (the next instruction to execute in case of SQL continue
handlers) is evaluated.
This is achieved with sp_instr::exec_open_and_lock_tables()
6) if a user exception handler is present in the stored routine, that
handler is invoked as usual, so that ER_NO_SUCH_TABLE exceptions can be
trapped by stored routines. If no handler exists, then the runtime execution
will fail as expected.
With all these changes, a side effect is that view security is impacted, in
two different ways.
First, a view defined as "select stored_function()", where the stored
function references a table that may not exist, is considered valid.
The rationale is that, because the stored function might trap exceptions
during execution and still return a valid result, there is no way to decide
when the view is created if a missing table really cause the view to be invalid.
Secondly, testing for existence of tables is now done later during
execution. View security, which consist of trapping errors and return a
generic ER_VIEW_INVALID (to prevent disclosing information) was only
implemented at very specific phases covering *opening* tables, but not
covering the runtime execution. Because of this existing limitation,
errors that were previously trapped and converted into ER_VIEW_INVALID are
not trapped, causing table names to be reported to the user.
This change is exposing an existing problem, which is independent and will
be resolved separately.
2007-03-06 03:42:07 +01:00
|
|
|
|
2005-03-04 14:35:28 +01:00
|
|
|
/*
|
|
|
|
Execute core function of instruction after all preparations (e.g.
|
|
|
|
setting of proper LEX, saving part of the thread context have been
|
|
|
|
done).
|
|
|
|
|
|
|
|
Should be implemented for instructions using expressions or whole
|
|
|
|
statements (thus having to have own LEX). Used in concert with
|
2005-08-25 15:34:34 +02:00
|
|
|
sp_lex_keeper class and its descendants (there are none currently).
|
2005-03-04 14:35:28 +01:00
|
|
|
*/
|
|
|
|
virtual int exec_core(THD *thd, uint *nextp);
|
|
|
|
|
2004-03-29 11:16:45 +02:00
|
|
|
virtual void print(String *str) = 0;
|
Simplistic, experimental framework for Stored Procedures (SPs).
Implements creation and dropping of PROCEDUREs, IN, OUT, and INOUT parameters,
single-statement procedures, rudimentary multi-statement (begin-end) prodedures
(when the client can handle it), and local variables.
Missing most of the embedded SQL language, all attributes, FUNCTIONs, error handling,
reparses procedures at each call (no caching), etc, etc.
Certainly buggy too, but procedures can actually be created and called....
2002-12-08 19:59:22 +01:00
|
|
|
|
2004-08-26 12:54:30 +02:00
|
|
|
virtual void backpatch(uint dest, sp_pcontext *dst_ctx)
|
2004-08-02 18:05:31 +02:00
|
|
|
{}
|
2002-12-11 14:24:29 +01:00
|
|
|
|
2006-01-25 15:11:49 +01:00
|
|
|
/*
|
|
|
|
Mark this instruction as reachable during optimization and return the
|
Bug#19194 (Right recursion in parser for CASE causes excessive stack usage,
limitation)
Note to the reviewer
====================
Warning: reviewing this patch is somewhat involved.
Due to the nature of several issues all affecting the same area,
fixing separately each issue is not practical, since each fix can not be
implemented and tested independently.
In particular, the issues with
- rule recursion
- nested case statements
- forward jump resolution (backpatch list)
are tightly coupled (see below).
Definitions
===========
The expression
CASE expr
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Simple Case Expression".
The expression
CASE
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Searched Case Expression".
The statement
CASE expr
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Simple Case Statement".
The statement
CASE
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Searched Case Statement".
A "Left Recursive" rule is like
list:
element
| list element
;
A "Right Recursive" rule is like
list:
element
| element list
;
Left and right recursion produces the same language, the difference only
affects the *order* in which the text is parsed.
In a descendant parser (usually written manually), right recursion works
very well, and is typically implemented with a while loop.
In an ascendant parser (yacc/bison) left recursion works very well,
and is implemented naturally by the parser stack.
In both cases, using the wrong type or recursion is very bad and should be
avoided, as it causes technical issues with the parser implementation.
Before this change
==================
The "Simple Case Expression" and "Searched Case Expression" were both
implemented by the "when_list" and "when_list2" rules, which are left
recursive (ok).
These rules, however, used lex->when_list instead of using the parser stack,
which is more complex that necessary, and potentially dangerous because
of other rules using THD::reset_lex.
The "Simple Case Statement" and "Searched Case Statements" were implemented
by the "sp_case", "sp_whens" and in part by "sp_proc_stmt" rules.
Both cases were right recursive (bad).
The grammar involved was convoluted, and is assumed to be the results of
tweaks to get the code generation to work, but is not what someone would
naturally write.
In addition, using a common rule for both "Simple" and "Searched" case
statements was implemented with sp_head::m_flags |= IN_SIMPLE_CASE,
which is a flag and not a stack, and therefore does not take into account
*nested* case statements. This leads to incorrect generated code, and either
a server crash or an incorrect result.
With regards to the backpatch mechanism, a *different* backpatch list was
created for each jump from "WHEN expr THEN stmt" to "END CASE", which
relied on the grammar to be right recursive.
This is a mis-use of the backpatch list, since this list can resolve
multiple references to the same target at once.
The optimizer algorithm used to detect dead code in the "assembly" SQL
instructions, implemented by sp_head::opt_mark(uint ip), was recursive
in some cases (a conditional jump pointing forward to another conditional
jump).
In case of specially crafted code, like
- a long list of "IF expr THEN stmt END IF"
- a long CASE statement
this would actually cause a server crash with a stack overflow.
In general, having a stack that grows proportionally with user data (the
SQL code given by the client in a CREATE PROCEDURE) is to be avoided.
In debug builds only, creating a SP / SF / Trigger which had a significant
amount of code would spend --literally-- several minutes in sp_head::create,
because of the debug code involved with DBUG_PRINT("info", ("Code %s ...
There are several issues with this code:
- in a CASE with 5 000 WHEN, there are 15 000 instructions generated,
which create a sting representation of the code which is 500 000 bytes
long,
- using a String instead of an io stream causes performances to degrade
to a total server freeze, as time is spent doing realloc of a buffer
always too short,
- Printing a 500 000 long string in the debug log is too verbose,
- Generating this string even when DBUG_PRINT is off is useless,
- Having code that potentially can affect the server behavior, used with
#ifdef / #endif is useful in some cases, but is also a bad practice.
After this change
=================
"Case Expressions" (both simple and searched) have been simplified to
not use LEX::when_list, which has been removed.
Considering all the issues affecting case statements, the grammar for these
has been totally re written.
The existing actions, used to generate "assembly" sp_inst* code, have been
preserved but moved in the new grammar, with the following changes:
a) Bison rules are no longer shared between "Simple" and "Searched" case
statements, because a stack instead of a flag is required to handle them.
Nested statements are handled naturally by the parser stack, which by
definition uses the correct rule in the correct context.
Nested statements of the opposite type (simple vs searched) works correctly.
The flag sp_head::IN_SIMPLE_CASE is no longer used.
This is a step towards resolution of WL#2999, which correctly identified
that temporary parsing flags do not belong to sp_head.
The code in the action is shared by mean of the case_stmt_action_xxx()
helpers.
b) The backpatch mechanism, used to resolve forward jumps in the generated
code, has been changed to:
- create a label for the instruction following 'END CASE',
- register each jump at the end of a "WHEN expr THEN stmt" in a *unique*
backpatch list associated with the 'END CASE' label
- resolve all the forward jumps for this label at once.
In addition, the code involving backpatch has been commented, so that a
reader can now understand by reading matching "Registering" and "Resolving"
comments how the forward jumps are resolved and what target they resolve to,
as this is far from evident when reading the code alone.
The implementation of sp_head::opt_mark() has been revised to avoid
recursive calls from jump instructions, and instead add the jump location
to the list of paths to explore during the flow analysis of the instruction
graph, with a call to sp_head::add_mark_lead().
In addition, the flow analysis will stop if an instruction has already
been marked as reachable, which the previous code failed to do in the
recursive case.
sp_head::opt_mark() is now private, to prevent new calls to this method from
being introduced.
The debug code present in sp_head::create() has been removed.
Considering that SHOW PROCEDURE CODE is also available in debug builds,
and can be used anytime regardless of the trace level, as opposed to
"CREATE PROCEDURE" time and only if the trace was on,
removing the code actually makes debugging easier (usable trace).
Tests have been written to cover the parser overflow (big CASE),
and to cover nested CASE statements.
2006-11-17 20:14:29 +01:00
|
|
|
index to the next instruction. Jump instruction will add their
|
|
|
|
destination to the leads list.
|
2006-01-25 15:11:49 +01:00
|
|
|
*/
|
Bug#19194 (Right recursion in parser for CASE causes excessive stack usage,
limitation)
Note to the reviewer
====================
Warning: reviewing this patch is somewhat involved.
Due to the nature of several issues all affecting the same area,
fixing separately each issue is not practical, since each fix can not be
implemented and tested independently.
In particular, the issues with
- rule recursion
- nested case statements
- forward jump resolution (backpatch list)
are tightly coupled (see below).
Definitions
===========
The expression
CASE expr
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Simple Case Expression".
The expression
CASE
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Searched Case Expression".
The statement
CASE expr
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Simple Case Statement".
The statement
CASE
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Searched Case Statement".
A "Left Recursive" rule is like
list:
element
| list element
;
A "Right Recursive" rule is like
list:
element
| element list
;
Left and right recursion produces the same language, the difference only
affects the *order* in which the text is parsed.
In a descendant parser (usually written manually), right recursion works
very well, and is typically implemented with a while loop.
In an ascendant parser (yacc/bison) left recursion works very well,
and is implemented naturally by the parser stack.
In both cases, using the wrong type or recursion is very bad and should be
avoided, as it causes technical issues with the parser implementation.
Before this change
==================
The "Simple Case Expression" and "Searched Case Expression" were both
implemented by the "when_list" and "when_list2" rules, which are left
recursive (ok).
These rules, however, used lex->when_list instead of using the parser stack,
which is more complex that necessary, and potentially dangerous because
of other rules using THD::reset_lex.
The "Simple Case Statement" and "Searched Case Statements" were implemented
by the "sp_case", "sp_whens" and in part by "sp_proc_stmt" rules.
Both cases were right recursive (bad).
The grammar involved was convoluted, and is assumed to be the results of
tweaks to get the code generation to work, but is not what someone would
naturally write.
In addition, using a common rule for both "Simple" and "Searched" case
statements was implemented with sp_head::m_flags |= IN_SIMPLE_CASE,
which is a flag and not a stack, and therefore does not take into account
*nested* case statements. This leads to incorrect generated code, and either
a server crash or an incorrect result.
With regards to the backpatch mechanism, a *different* backpatch list was
created for each jump from "WHEN expr THEN stmt" to "END CASE", which
relied on the grammar to be right recursive.
This is a mis-use of the backpatch list, since this list can resolve
multiple references to the same target at once.
The optimizer algorithm used to detect dead code in the "assembly" SQL
instructions, implemented by sp_head::opt_mark(uint ip), was recursive
in some cases (a conditional jump pointing forward to another conditional
jump).
In case of specially crafted code, like
- a long list of "IF expr THEN stmt END IF"
- a long CASE statement
this would actually cause a server crash with a stack overflow.
In general, having a stack that grows proportionally with user data (the
SQL code given by the client in a CREATE PROCEDURE) is to be avoided.
In debug builds only, creating a SP / SF / Trigger which had a significant
amount of code would spend --literally-- several minutes in sp_head::create,
because of the debug code involved with DBUG_PRINT("info", ("Code %s ...
There are several issues with this code:
- in a CASE with 5 000 WHEN, there are 15 000 instructions generated,
which create a sting representation of the code which is 500 000 bytes
long,
- using a String instead of an io stream causes performances to degrade
to a total server freeze, as time is spent doing realloc of a buffer
always too short,
- Printing a 500 000 long string in the debug log is too verbose,
- Generating this string even when DBUG_PRINT is off is useless,
- Having code that potentially can affect the server behavior, used with
#ifdef / #endif is useful in some cases, but is also a bad practice.
After this change
=================
"Case Expressions" (both simple and searched) have been simplified to
not use LEX::when_list, which has been removed.
Considering all the issues affecting case statements, the grammar for these
has been totally re written.
The existing actions, used to generate "assembly" sp_inst* code, have been
preserved but moved in the new grammar, with the following changes:
a) Bison rules are no longer shared between "Simple" and "Searched" case
statements, because a stack instead of a flag is required to handle them.
Nested statements are handled naturally by the parser stack, which by
definition uses the correct rule in the correct context.
Nested statements of the opposite type (simple vs searched) works correctly.
The flag sp_head::IN_SIMPLE_CASE is no longer used.
This is a step towards resolution of WL#2999, which correctly identified
that temporary parsing flags do not belong to sp_head.
The code in the action is shared by mean of the case_stmt_action_xxx()
helpers.
b) The backpatch mechanism, used to resolve forward jumps in the generated
code, has been changed to:
- create a label for the instruction following 'END CASE',
- register each jump at the end of a "WHEN expr THEN stmt" in a *unique*
backpatch list associated with the 'END CASE' label
- resolve all the forward jumps for this label at once.
In addition, the code involving backpatch has been commented, so that a
reader can now understand by reading matching "Registering" and "Resolving"
comments how the forward jumps are resolved and what target they resolve to,
as this is far from evident when reading the code alone.
The implementation of sp_head::opt_mark() has been revised to avoid
recursive calls from jump instructions, and instead add the jump location
to the list of paths to explore during the flow analysis of the instruction
graph, with a call to sp_head::add_mark_lead().
In addition, the flow analysis will stop if an instruction has already
been marked as reachable, which the previous code failed to do in the
recursive case.
sp_head::opt_mark() is now private, to prevent new calls to this method from
being introduced.
The debug code present in sp_head::create() has been removed.
Considering that SHOW PROCEDURE CODE is also available in debug builds,
and can be used anytime regardless of the trace level, as opposed to
"CREATE PROCEDURE" time and only if the trace was on,
removing the code actually makes debugging easier (usable trace).
Tests have been written to cover the parser overflow (big CASE),
and to cover nested CASE statements.
2006-11-17 20:14:29 +01:00
|
|
|
virtual uint opt_mark(sp_head *sp, List<sp_instr> *leads)
|
2004-08-02 18:05:31 +02:00
|
|
|
{
|
|
|
|
marked= 1;
|
|
|
|
return m_ip+1;
|
|
|
|
}
|
|
|
|
|
2006-01-25 15:11:49 +01:00
|
|
|
/*
|
|
|
|
Short-cut jumps to jumps during optimization. This is used by the
|
|
|
|
jump instructions' opt_mark() methods. 'start' is the starting point,
|
|
|
|
used to prevent the mark sweep from looping for ever. Return the
|
|
|
|
end destination.
|
|
|
|
*/
|
2004-08-26 12:54:30 +02:00
|
|
|
virtual uint opt_shortcut_jump(sp_head *sp, sp_instr *start)
|
2004-08-02 18:05:31 +02:00
|
|
|
{
|
|
|
|
return m_ip;
|
|
|
|
}
|
|
|
|
|
2006-01-25 15:11:49 +01:00
|
|
|
/*
|
|
|
|
Inform the instruction that it has been moved during optimization.
|
|
|
|
Most instructions will simply update its index, but jump instructions
|
|
|
|
must also take care of their destination pointers. Forward jumps get
|
|
|
|
pushed to the backpatch list 'ibp'.
|
|
|
|
*/
|
2004-08-02 18:05:31 +02:00
|
|
|
virtual void opt_move(uint dst, List<sp_instr> *ibp)
|
|
|
|
{
|
|
|
|
m_ip= dst;
|
|
|
|
}
|
2002-12-11 14:24:29 +01:00
|
|
|
|
Simplistic, experimental framework for Stored Procedures (SPs).
Implements creation and dropping of PROCEDUREs, IN, OUT, and INOUT parameters,
single-statement procedures, rudimentary multi-statement (begin-end) prodedures
(when the client can handle it), and local variables.
Missing most of the embedded SQL language, all attributes, FUNCTIONs, error handling,
reparses procedures at each call (no caching), etc, etc.
Certainly buggy too, but procedures can actually be created and called....
2002-12-08 19:59:22 +01:00
|
|
|
}; // class sp_instr : public Sql_alloc
|
|
|
|
|
|
|
|
|
2005-03-04 14:35:28 +01:00
|
|
|
/*
|
|
|
|
Auxilary class to which instructions delegate responsibility
|
|
|
|
for handling LEX and preparations before executing statement
|
|
|
|
or calculating complex expression.
|
|
|
|
|
|
|
|
Exist mainly to avoid having double hierarchy between instruction
|
|
|
|
classes.
|
|
|
|
|
|
|
|
TODO: Add ability to not store LEX and do any preparations if
|
|
|
|
expression used is simple.
|
|
|
|
*/
|
|
|
|
|
|
|
|
class sp_lex_keeper
|
|
|
|
{
|
|
|
|
/* Prevent use of these */
|
|
|
|
sp_lex_keeper(const sp_lex_keeper &);
|
|
|
|
void operator=(sp_lex_keeper &);
|
|
|
|
public:
|
|
|
|
|
|
|
|
sp_lex_keeper(LEX *lex, bool lex_resp)
|
2005-07-30 10:19:57 +02:00
|
|
|
: m_lex(lex), m_lex_resp(lex_resp),
|
|
|
|
lex_query_tables_own_last(NULL)
|
2005-03-04 14:35:28 +01:00
|
|
|
{
|
|
|
|
lex->sp_lex_in_use= TRUE;
|
|
|
|
}
|
|
|
|
virtual ~sp_lex_keeper()
|
|
|
|
{
|
|
|
|
if (m_lex_resp)
|
2006-05-04 14:30:38 +02:00
|
|
|
{
|
|
|
|
lex_end(m_lex);
|
2005-03-04 14:35:28 +01:00
|
|
|
delete m_lex;
|
2006-05-04 14:30:38 +02:00
|
|
|
}
|
2005-03-04 14:35:28 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
Prepare execution of instruction using LEX, if requested check whenever
|
|
|
|
we have read access to tables used and open/lock them, call instruction's
|
|
|
|
exec_core() method, perform cleanup afterwards.
|
|
|
|
*/
|
|
|
|
int reset_lex_and_exec_core(THD *thd, uint *nextp, bool open_tables,
|
|
|
|
sp_instr* instr);
|
|
|
|
|
|
|
|
inline uint sql_command() const
|
|
|
|
{
|
|
|
|
return (uint)m_lex->sql_command;
|
|
|
|
}
|
|
|
|
|
2005-06-14 21:45:48 +02:00
|
|
|
void disable_query_cache()
|
|
|
|
{
|
|
|
|
m_lex->safe_to_cache_query= 0;
|
|
|
|
}
|
2005-03-04 14:35:28 +01:00
|
|
|
private:
|
|
|
|
|
|
|
|
LEX *m_lex;
|
|
|
|
/*
|
|
|
|
Indicates whenever this sp_lex_keeper instance responsible
|
|
|
|
for LEX deletion.
|
|
|
|
*/
|
|
|
|
bool m_lex_resp;
|
2005-07-30 10:19:57 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
Support for being able to execute this statement in two modes:
|
|
|
|
a) inside prelocked mode set by the calling procedure or its ancestor.
|
|
|
|
b) outside of prelocked mode, when this statement enters/leaves
|
|
|
|
prelocked mode itself.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
List of additional tables this statement needs to lock when it
|
|
|
|
enters/leaves prelocked mode on its own.
|
|
|
|
*/
|
|
|
|
TABLE_LIST *prelocking_tables;
|
|
|
|
|
|
|
|
/*
|
|
|
|
The value m_lex->query_tables_own_last should be set to this when the
|
|
|
|
statement enters/leaves prelocked mode on its own.
|
|
|
|
*/
|
|
|
|
TABLE_LIST **lex_query_tables_own_last;
|
2005-03-04 14:35:28 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
|
Simplistic, experimental framework for Stored Procedures (SPs).
Implements creation and dropping of PROCEDUREs, IN, OUT, and INOUT parameters,
single-statement procedures, rudimentary multi-statement (begin-end) prodedures
(when the client can handle it), and local variables.
Missing most of the embedded SQL language, all attributes, FUNCTIONs, error handling,
reparses procedures at each call (no caching), etc, etc.
Certainly buggy too, but procedures can actually be created and called....
2002-12-08 19:59:22 +01:00
|
|
|
//
|
|
|
|
// Call out to some prepared SQL statement.
|
|
|
|
//
|
|
|
|
class sp_instr_stmt : public sp_instr
|
|
|
|
{
|
|
|
|
sp_instr_stmt(const sp_instr_stmt &); /* Prevent use of these */
|
|
|
|
void operator=(sp_instr_stmt &);
|
|
|
|
|
|
|
|
public:
|
|
|
|
|
2004-09-17 15:40:38 +02:00
|
|
|
LEX_STRING m_query; // For thd->query
|
|
|
|
|
2005-03-04 14:35:28 +01:00
|
|
|
sp_instr_stmt(uint ip, sp_pcontext *ctx, LEX *lex)
|
|
|
|
: sp_instr(ip, ctx), m_lex_keeper(lex, TRUE)
|
2004-09-17 15:40:38 +02:00
|
|
|
{
|
|
|
|
m_query.str= 0;
|
|
|
|
m_query.length= 0;
|
|
|
|
}
|
Simplistic, experimental framework for Stored Procedures (SPs).
Implements creation and dropping of PROCEDUREs, IN, OUT, and INOUT parameters,
single-statement procedures, rudimentary multi-statement (begin-end) prodedures
(when the client can handle it), and local variables.
Missing most of the embedded SQL language, all attributes, FUNCTIONs, error handling,
reparses procedures at each call (no caching), etc, etc.
Certainly buggy too, but procedures can actually be created and called....
2002-12-08 19:59:22 +01:00
|
|
|
|
2005-03-04 14:35:28 +01:00
|
|
|
virtual ~sp_instr_stmt()
|
|
|
|
{};
|
Simplistic, experimental framework for Stored Procedures (SPs).
Implements creation and dropping of PROCEDUREs, IN, OUT, and INOUT parameters,
single-statement procedures, rudimentary multi-statement (begin-end) prodedures
(when the client can handle it), and local variables.
Missing most of the embedded SQL language, all attributes, FUNCTIONs, error handling,
reparses procedures at each call (no caching), etc, etc.
Certainly buggy too, but procedures can actually be created and called....
2002-12-08 19:59:22 +01:00
|
|
|
|
2002-12-11 14:24:29 +01:00
|
|
|
virtual int execute(THD *thd, uint *nextp);
|
Simplistic, experimental framework for Stored Procedures (SPs).
Implements creation and dropping of PROCEDUREs, IN, OUT, and INOUT parameters,
single-statement procedures, rudimentary multi-statement (begin-end) prodedures
(when the client can handle it), and local variables.
Missing most of the embedded SQL language, all attributes, FUNCTIONs, error handling,
reparses procedures at each call (no caching), etc, etc.
Certainly buggy too, but procedures can actually be created and called....
2002-12-08 19:59:22 +01:00
|
|
|
|
2005-03-04 14:35:28 +01:00
|
|
|
virtual int exec_core(THD *thd, uint *nextp);
|
Simplistic, experimental framework for Stored Procedures (SPs).
Implements creation and dropping of PROCEDUREs, IN, OUT, and INOUT parameters,
single-statement procedures, rudimentary multi-statement (begin-end) prodedures
(when the client can handle it), and local variables.
Missing most of the embedded SQL language, all attributes, FUNCTIONs, error handling,
reparses procedures at each call (no caching), etc, etc.
Certainly buggy too, but procedures can actually be created and called....
2002-12-08 19:59:22 +01:00
|
|
|
|
2005-03-04 14:35:28 +01:00
|
|
|
virtual void print(String *str);
|
2003-10-10 16:57:21 +02:00
|
|
|
|
Simplistic, experimental framework for Stored Procedures (SPs).
Implements creation and dropping of PROCEDUREs, IN, OUT, and INOUT parameters,
single-statement procedures, rudimentary multi-statement (begin-end) prodedures
(when the client can handle it), and local variables.
Missing most of the embedded SQL language, all attributes, FUNCTIONs, error handling,
reparses procedures at each call (no caching), etc, etc.
Certainly buggy too, but procedures can actually be created and called....
2002-12-08 19:59:22 +01:00
|
|
|
private:
|
|
|
|
|
2005-03-04 14:35:28 +01:00
|
|
|
sp_lex_keeper m_lex_keeper;
|
Simplistic, experimental framework for Stored Procedures (SPs).
Implements creation and dropping of PROCEDUREs, IN, OUT, and INOUT parameters,
single-statement procedures, rudimentary multi-statement (begin-end) prodedures
(when the client can handle it), and local variables.
Missing most of the embedded SQL language, all attributes, FUNCTIONs, error handling,
reparses procedures at each call (no caching), etc, etc.
Certainly buggy too, but procedures can actually be created and called....
2002-12-08 19:59:22 +01:00
|
|
|
|
|
|
|
}; // class sp_instr_stmt : public sp_instr
|
|
|
|
|
|
|
|
|
|
|
|
class sp_instr_set : public sp_instr
|
|
|
|
{
|
|
|
|
sp_instr_set(const sp_instr_set &); /* Prevent use of these */
|
|
|
|
void operator=(sp_instr_set &);
|
|
|
|
|
|
|
|
public:
|
|
|
|
|
2004-08-26 12:54:30 +02:00
|
|
|
sp_instr_set(uint ip, sp_pcontext *ctx,
|
2006-12-14 23:51:37 +01:00
|
|
|
uint offset, Item *val, enum enum_field_types type_arg,
|
2005-03-04 14:35:28 +01:00
|
|
|
LEX *lex, bool lex_resp)
|
2006-12-14 23:51:37 +01:00
|
|
|
: sp_instr(ip, ctx), m_offset(offset), m_value(val), m_type(type_arg),
|
2005-03-04 14:35:28 +01:00
|
|
|
m_lex_keeper(lex, lex_resp)
|
Simplistic, experimental framework for Stored Procedures (SPs).
Implements creation and dropping of PROCEDUREs, IN, OUT, and INOUT parameters,
single-statement procedures, rudimentary multi-statement (begin-end) prodedures
(when the client can handle it), and local variables.
Missing most of the embedded SQL language, all attributes, FUNCTIONs, error handling,
reparses procedures at each call (no caching), etc, etc.
Certainly buggy too, but procedures can actually be created and called....
2002-12-08 19:59:22 +01:00
|
|
|
{}
|
|
|
|
|
|
|
|
virtual ~sp_instr_set()
|
|
|
|
{}
|
|
|
|
|
2002-12-11 14:24:29 +01:00
|
|
|
virtual int execute(THD *thd, uint *nextp);
|
Simplistic, experimental framework for Stored Procedures (SPs).
Implements creation and dropping of PROCEDUREs, IN, OUT, and INOUT parameters,
single-statement procedures, rudimentary multi-statement (begin-end) prodedures
(when the client can handle it), and local variables.
Missing most of the embedded SQL language, all attributes, FUNCTIONs, error handling,
reparses procedures at each call (no caching), etc, etc.
Certainly buggy too, but procedures can actually be created and called....
2002-12-08 19:59:22 +01:00
|
|
|
|
2005-03-04 14:35:28 +01:00
|
|
|
virtual int exec_core(THD *thd, uint *nextp);
|
|
|
|
|
2004-03-29 11:16:45 +02:00
|
|
|
virtual void print(String *str);
|
|
|
|
|
Simplistic, experimental framework for Stored Procedures (SPs).
Implements creation and dropping of PROCEDUREs, IN, OUT, and INOUT parameters,
single-statement procedures, rudimentary multi-statement (begin-end) prodedures
(when the client can handle it), and local variables.
Missing most of the embedded SQL language, all attributes, FUNCTIONs, error handling,
reparses procedures at each call (no caching), etc, etc.
Certainly buggy too, but procedures can actually be created and called....
2002-12-08 19:59:22 +01:00
|
|
|
private:
|
|
|
|
|
2002-12-11 14:24:29 +01:00
|
|
|
uint m_offset; // Frame offset
|
Simplistic, experimental framework for Stored Procedures (SPs).
Implements creation and dropping of PROCEDUREs, IN, OUT, and INOUT parameters,
single-statement procedures, rudimentary multi-statement (begin-end) prodedures
(when the client can handle it), and local variables.
Missing most of the embedded SQL language, all attributes, FUNCTIONs, error handling,
reparses procedures at each call (no caching), etc, etc.
Certainly buggy too, but procedures can actually be created and called....
2002-12-08 19:59:22 +01:00
|
|
|
Item *m_value;
|
|
|
|
enum enum_field_types m_type; // The declared type
|
2005-03-04 14:35:28 +01:00
|
|
|
sp_lex_keeper m_lex_keeper;
|
Simplistic, experimental framework for Stored Procedures (SPs).
Implements creation and dropping of PROCEDUREs, IN, OUT, and INOUT parameters,
single-statement procedures, rudimentary multi-statement (begin-end) prodedures
(when the client can handle it), and local variables.
Missing most of the embedded SQL language, all attributes, FUNCTIONs, error handling,
reparses procedures at each call (no caching), etc, etc.
Certainly buggy too, but procedures can actually be created and called....
2002-12-08 19:59:22 +01:00
|
|
|
|
|
|
|
}; // class sp_instr_set : public sp_instr
|
|
|
|
|
2002-12-11 14:24:29 +01:00
|
|
|
|
2004-09-07 14:29:46 +02:00
|
|
|
/*
|
|
|
|
Set NEW/OLD row field value instruction. Used in triggers.
|
|
|
|
*/
|
|
|
|
class sp_instr_set_trigger_field : public sp_instr
|
|
|
|
{
|
|
|
|
sp_instr_set_trigger_field(const sp_instr_set_trigger_field &);
|
|
|
|
void operator=(sp_instr_set_trigger_field &);
|
|
|
|
|
|
|
|
public:
|
|
|
|
|
2004-09-08 22:46:01 +02:00
|
|
|
sp_instr_set_trigger_field(uint ip, sp_pcontext *ctx,
|
2005-07-09 19:51:59 +02:00
|
|
|
Item_trigger_field *trg_fld,
|
|
|
|
Item *val, LEX *lex)
|
2004-09-08 22:46:01 +02:00
|
|
|
: sp_instr(ip, ctx),
|
2005-05-27 12:15:17 +02:00
|
|
|
trigger_field(trg_fld),
|
2005-07-09 19:51:59 +02:00
|
|
|
value(val), m_lex_keeper(lex, TRUE)
|
2004-09-07 14:29:46 +02:00
|
|
|
{}
|
|
|
|
|
|
|
|
virtual ~sp_instr_set_trigger_field()
|
|
|
|
{}
|
|
|
|
|
|
|
|
virtual int execute(THD *thd, uint *nextp);
|
|
|
|
|
2005-07-09 19:51:59 +02:00
|
|
|
virtual int exec_core(THD *thd, uint *nextp);
|
|
|
|
|
2004-09-07 14:29:46 +02:00
|
|
|
virtual void print(String *str);
|
|
|
|
|
2004-11-24 10:24:02 +01:00
|
|
|
private:
|
2005-05-27 12:15:17 +02:00
|
|
|
Item_trigger_field *trigger_field;
|
2004-09-07 14:29:46 +02:00
|
|
|
Item *value;
|
2005-07-09 19:51:59 +02:00
|
|
|
sp_lex_keeper m_lex_keeper;
|
2004-09-07 14:29:46 +02:00
|
|
|
}; // class sp_instr_trigger_field : public sp_instr
|
|
|
|
|
|
|
|
|
2006-01-26 17:26:25 +01:00
|
|
|
/*
|
|
|
|
An abstract class for all instructions with destinations that
|
|
|
|
needs to be updated by the optimizer.
|
|
|
|
Even if not all subclasses will use both the normal destination and
|
|
|
|
the continuation destination, we put them both here for simplicity.
|
|
|
|
*/
|
|
|
|
class sp_instr_opt_meta : public sp_instr
|
|
|
|
{
|
|
|
|
public:
|
|
|
|
|
|
|
|
uint m_dest; // Where we will go
|
|
|
|
uint m_cont_dest; // Where continue handlers will go
|
|
|
|
|
|
|
|
sp_instr_opt_meta(uint ip, sp_pcontext *ctx)
|
|
|
|
: sp_instr(ip, ctx),
|
|
|
|
m_dest(0), m_cont_dest(0), m_optdest(0), m_cont_optdest(0)
|
|
|
|
{}
|
|
|
|
|
|
|
|
sp_instr_opt_meta(uint ip, sp_pcontext *ctx, uint dest)
|
|
|
|
: sp_instr(ip, ctx),
|
|
|
|
m_dest(dest), m_cont_dest(0), m_optdest(0), m_cont_optdest(0)
|
|
|
|
{}
|
|
|
|
|
|
|
|
virtual ~sp_instr_opt_meta()
|
|
|
|
{}
|
|
|
|
|
|
|
|
virtual void set_destination(uint old_dest, uint new_dest)
|
|
|
|
= 0;
|
|
|
|
|
2007-03-07 17:53:46 +01:00
|
|
|
virtual uint get_cont_dest();
|
Bug#8407 (Stored functions/triggers ignore exception handler)
Bug 18914 (Calling certain SPs from triggers fail)
Bug 20713 (Functions will not not continue for SQLSTATE VALUE '42S02')
Bug 21825 (Incorrect message error deleting records in a table with a
trigger for inserting)
Bug 22580 (DROP TABLE in nested stored procedure causes strange dependency
error)
Bug 25345 (Cursors from Functions)
This fix resolves a long standing issue originally reported with bug 8407,
which affect the behavior of Stored Procedures, Stored Functions and Trigger
in many different ways, causing symptoms reported by all the bugs listed.
In all cases, the root cause of the problem traces back to 8407 and how the
server locks tables involved with sub statements.
Prior to this fix, the implementation of stored routines would:
- compute the transitive closure of all the tables referenced by a top level
statement
- open and lock all the tables involved
- execute the top level statement
"transitive closure of tables" means collecting:
- all the tables,
- all the stored functions,
- all the views,
- all the table triggers
- all the stored procedures
involved, and recursively inspect these objects definition to find more
references to more objects, until the list of every object referenced does
not grow any more.
This mechanism is known as "pre-locking" tables before execution.
The motivation for locking all the tables (possibly) used at once is to
prevent dead locks.
One problem with this approach is that, if the execution path the code
really takes during runtime does not use a given table, and if the table is
missing, the server would not execute the statement.
This in particular has a major impact on triggers, since a missing table
referenced by an update/delete trigger would prevent an insert trigger to run.
Another problem is that stored routines might define SQL exception handlers
to deal with missing tables, but the server implementation would never give
user code a chance to execute this logic, since the routine is never
executed when a missing table cause the pre-locking code to fail.
With this fix, the internal implementation of the pre-locking code has been
relaxed of some constraints, so that failure to open a table does not
necessarily prevent execution of a stored routine.
In particular, the pre-locking mechanism is now behaving as follows:
1) the first step, to compute the transitive closure of all the tables
possibly referenced by a statement, is unchanged.
2) the next step, which is to open all the tables involved, only attempts
to open the tables added by the pre-locking code, but silently fails without
reporting any error or invoking any exception handler is the table is not
present. This is achieved by trapping internal errors with
Prelock_error_handler
3) the locking step only locks tables that were successfully opened.
4) when executing sub statements, the list of tables used by each statements
is evaluated as before. The tables needed by the sub statement are expected
to be already opened and locked. Statement referencing tables that were not
opened in step 2) will fail to find the table in the open list, and only at
this point will execution of the user code fail.
5) when a runtime exception is raised at 4), the instruction continuation
destination (the next instruction to execute in case of SQL continue
handlers) is evaluated.
This is achieved with sp_instr::exec_open_and_lock_tables()
6) if a user exception handler is present in the stored routine, that
handler is invoked as usual, so that ER_NO_SUCH_TABLE exceptions can be
trapped by stored routines. If no handler exists, then the runtime execution
will fail as expected.
With all these changes, a side effect is that view security is impacted, in
two different ways.
First, a view defined as "select stored_function()", where the stored
function references a table that may not exist, is considered valid.
The rationale is that, because the stored function might trap exceptions
during execution and still return a valid result, there is no way to decide
when the view is created if a missing table really cause the view to be invalid.
Secondly, testing for existence of tables is now done later during
execution. View security, which consist of trapping errors and return a
generic ER_VIEW_INVALID (to prevent disclosing information) was only
implemented at very specific phases covering *opening* tables, but not
covering the runtime execution. Because of this existing limitation,
errors that were previously trapped and converted into ER_VIEW_INVALID are
not trapped, causing table names to be reported to the user.
This change is exposing an existing problem, which is independent and will
be resolved separately.
2007-03-06 03:42:07 +01:00
|
|
|
|
2006-01-26 17:26:25 +01:00
|
|
|
protected:
|
|
|
|
|
|
|
|
sp_instr *m_optdest; // Used during optimization
|
|
|
|
sp_instr *m_cont_optdest; // Used during optimization
|
|
|
|
|
|
|
|
}; // class sp_instr_opt_meta : public sp_instr
|
|
|
|
|
|
|
|
class sp_instr_jump : public sp_instr_opt_meta
|
2002-12-11 14:24:29 +01:00
|
|
|
{
|
|
|
|
sp_instr_jump(const sp_instr_jump &); /* Prevent use of these */
|
|
|
|
void operator=(sp_instr_jump &);
|
|
|
|
|
|
|
|
public:
|
|
|
|
|
2004-08-26 12:54:30 +02:00
|
|
|
sp_instr_jump(uint ip, sp_pcontext *ctx)
|
2006-01-26 17:26:25 +01:00
|
|
|
: sp_instr_opt_meta(ip, ctx)
|
2002-12-11 14:24:29 +01:00
|
|
|
{}
|
|
|
|
|
2004-08-26 12:54:30 +02:00
|
|
|
sp_instr_jump(uint ip, sp_pcontext *ctx, uint dest)
|
2006-01-26 17:26:25 +01:00
|
|
|
: sp_instr_opt_meta(ip, ctx, dest)
|
2002-12-11 14:24:29 +01:00
|
|
|
{}
|
|
|
|
|
|
|
|
virtual ~sp_instr_jump()
|
|
|
|
{}
|
|
|
|
|
2003-03-05 19:45:17 +01:00
|
|
|
virtual int execute(THD *thd, uint *nextp);
|
2002-12-11 14:24:29 +01:00
|
|
|
|
2004-03-29 11:16:45 +02:00
|
|
|
virtual void print(String *str);
|
|
|
|
|
Bug#19194 (Right recursion in parser for CASE causes excessive stack usage,
limitation)
Note to the reviewer
====================
Warning: reviewing this patch is somewhat involved.
Due to the nature of several issues all affecting the same area,
fixing separately each issue is not practical, since each fix can not be
implemented and tested independently.
In particular, the issues with
- rule recursion
- nested case statements
- forward jump resolution (backpatch list)
are tightly coupled (see below).
Definitions
===========
The expression
CASE expr
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Simple Case Expression".
The expression
CASE
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Searched Case Expression".
The statement
CASE expr
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Simple Case Statement".
The statement
CASE
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Searched Case Statement".
A "Left Recursive" rule is like
list:
element
| list element
;
A "Right Recursive" rule is like
list:
element
| element list
;
Left and right recursion produces the same language, the difference only
affects the *order* in which the text is parsed.
In a descendant parser (usually written manually), right recursion works
very well, and is typically implemented with a while loop.
In an ascendant parser (yacc/bison) left recursion works very well,
and is implemented naturally by the parser stack.
In both cases, using the wrong type or recursion is very bad and should be
avoided, as it causes technical issues with the parser implementation.
Before this change
==================
The "Simple Case Expression" and "Searched Case Expression" were both
implemented by the "when_list" and "when_list2" rules, which are left
recursive (ok).
These rules, however, used lex->when_list instead of using the parser stack,
which is more complex that necessary, and potentially dangerous because
of other rules using THD::reset_lex.
The "Simple Case Statement" and "Searched Case Statements" were implemented
by the "sp_case", "sp_whens" and in part by "sp_proc_stmt" rules.
Both cases were right recursive (bad).
The grammar involved was convoluted, and is assumed to be the results of
tweaks to get the code generation to work, but is not what someone would
naturally write.
In addition, using a common rule for both "Simple" and "Searched" case
statements was implemented with sp_head::m_flags |= IN_SIMPLE_CASE,
which is a flag and not a stack, and therefore does not take into account
*nested* case statements. This leads to incorrect generated code, and either
a server crash or an incorrect result.
With regards to the backpatch mechanism, a *different* backpatch list was
created for each jump from "WHEN expr THEN stmt" to "END CASE", which
relied on the grammar to be right recursive.
This is a mis-use of the backpatch list, since this list can resolve
multiple references to the same target at once.
The optimizer algorithm used to detect dead code in the "assembly" SQL
instructions, implemented by sp_head::opt_mark(uint ip), was recursive
in some cases (a conditional jump pointing forward to another conditional
jump).
In case of specially crafted code, like
- a long list of "IF expr THEN stmt END IF"
- a long CASE statement
this would actually cause a server crash with a stack overflow.
In general, having a stack that grows proportionally with user data (the
SQL code given by the client in a CREATE PROCEDURE) is to be avoided.
In debug builds only, creating a SP / SF / Trigger which had a significant
amount of code would spend --literally-- several minutes in sp_head::create,
because of the debug code involved with DBUG_PRINT("info", ("Code %s ...
There are several issues with this code:
- in a CASE with 5 000 WHEN, there are 15 000 instructions generated,
which create a sting representation of the code which is 500 000 bytes
long,
- using a String instead of an io stream causes performances to degrade
to a total server freeze, as time is spent doing realloc of a buffer
always too short,
- Printing a 500 000 long string in the debug log is too verbose,
- Generating this string even when DBUG_PRINT is off is useless,
- Having code that potentially can affect the server behavior, used with
#ifdef / #endif is useful in some cases, but is also a bad practice.
After this change
=================
"Case Expressions" (both simple and searched) have been simplified to
not use LEX::when_list, which has been removed.
Considering all the issues affecting case statements, the grammar for these
has been totally re written.
The existing actions, used to generate "assembly" sp_inst* code, have been
preserved but moved in the new grammar, with the following changes:
a) Bison rules are no longer shared between "Simple" and "Searched" case
statements, because a stack instead of a flag is required to handle them.
Nested statements are handled naturally by the parser stack, which by
definition uses the correct rule in the correct context.
Nested statements of the opposite type (simple vs searched) works correctly.
The flag sp_head::IN_SIMPLE_CASE is no longer used.
This is a step towards resolution of WL#2999, which correctly identified
that temporary parsing flags do not belong to sp_head.
The code in the action is shared by mean of the case_stmt_action_xxx()
helpers.
b) The backpatch mechanism, used to resolve forward jumps in the generated
code, has been changed to:
- create a label for the instruction following 'END CASE',
- register each jump at the end of a "WHEN expr THEN stmt" in a *unique*
backpatch list associated with the 'END CASE' label
- resolve all the forward jumps for this label at once.
In addition, the code involving backpatch has been commented, so that a
reader can now understand by reading matching "Registering" and "Resolving"
comments how the forward jumps are resolved and what target they resolve to,
as this is far from evident when reading the code alone.
The implementation of sp_head::opt_mark() has been revised to avoid
recursive calls from jump instructions, and instead add the jump location
to the list of paths to explore during the flow analysis of the instruction
graph, with a call to sp_head::add_mark_lead().
In addition, the flow analysis will stop if an instruction has already
been marked as reachable, which the previous code failed to do in the
recursive case.
sp_head::opt_mark() is now private, to prevent new calls to this method from
being introduced.
The debug code present in sp_head::create() has been removed.
Considering that SHOW PROCEDURE CODE is also available in debug builds,
and can be used anytime regardless of the trace level, as opposed to
"CREATE PROCEDURE" time and only if the trace was on,
removing the code actually makes debugging easier (usable trace).
Tests have been written to cover the parser overflow (big CASE),
and to cover nested CASE statements.
2006-11-17 20:14:29 +01:00
|
|
|
virtual uint opt_mark(sp_head *sp, List<sp_instr> *leads);
|
2004-08-02 18:05:31 +02:00
|
|
|
|
2004-08-26 12:54:30 +02:00
|
|
|
virtual uint opt_shortcut_jump(sp_head *sp, sp_instr *start);
|
2004-08-02 18:05:31 +02:00
|
|
|
|
|
|
|
virtual void opt_move(uint dst, List<sp_instr> *ibp);
|
|
|
|
|
2004-08-26 12:54:30 +02:00
|
|
|
virtual void backpatch(uint dest, sp_pcontext *dst_ctx)
|
2002-12-11 14:24:29 +01:00
|
|
|
{
|
2004-04-05 17:01:19 +02:00
|
|
|
if (m_dest == 0) // Don't reset
|
|
|
|
m_dest= dest;
|
2002-12-11 14:24:29 +01:00
|
|
|
}
|
|
|
|
|
2006-01-25 15:11:49 +01:00
|
|
|
/*
|
|
|
|
Update the destination; used by the optimizer.
|
|
|
|
*/
|
2005-11-04 15:37:39 +01:00
|
|
|
virtual void set_destination(uint old_dest, uint new_dest)
|
2004-08-02 18:05:31 +02:00
|
|
|
{
|
2005-11-04 15:37:39 +01:00
|
|
|
if (m_dest == old_dest)
|
|
|
|
m_dest= new_dest;
|
2004-08-02 18:05:31 +02:00
|
|
|
}
|
|
|
|
|
2006-01-26 17:26:25 +01:00
|
|
|
}; // class sp_instr_jump : public sp_instr_opt_meta
|
2002-12-11 14:24:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
class sp_instr_jump_if_not : public sp_instr_jump
|
|
|
|
{
|
|
|
|
sp_instr_jump_if_not(const sp_instr_jump_if_not &); /* Prevent use of these */
|
|
|
|
void operator=(sp_instr_jump_if_not &);
|
|
|
|
|
|
|
|
public:
|
|
|
|
|
2005-03-04 14:35:28 +01:00
|
|
|
sp_instr_jump_if_not(uint ip, sp_pcontext *ctx, Item *i, LEX *lex)
|
2006-01-26 17:26:25 +01:00
|
|
|
: sp_instr_jump(ip, ctx), m_expr(i),
|
|
|
|
m_lex_keeper(lex, TRUE)
|
2002-12-11 14:24:29 +01:00
|
|
|
{}
|
|
|
|
|
2005-03-04 14:35:28 +01:00
|
|
|
sp_instr_jump_if_not(uint ip, sp_pcontext *ctx, Item *i, uint dest, LEX *lex)
|
2006-01-26 17:26:25 +01:00
|
|
|
: sp_instr_jump(ip, ctx, dest), m_expr(i),
|
|
|
|
m_lex_keeper(lex, TRUE)
|
2002-12-11 14:24:29 +01:00
|
|
|
{}
|
|
|
|
|
|
|
|
virtual ~sp_instr_jump_if_not()
|
|
|
|
{}
|
|
|
|
|
|
|
|
virtual int execute(THD *thd, uint *nextp);
|
|
|
|
|
2005-03-04 14:35:28 +01:00
|
|
|
virtual int exec_core(THD *thd, uint *nextp);
|
|
|
|
|
2004-03-29 11:16:45 +02:00
|
|
|
virtual void print(String *str);
|
|
|
|
|
Bug#19194 (Right recursion in parser for CASE causes excessive stack usage,
limitation)
Note to the reviewer
====================
Warning: reviewing this patch is somewhat involved.
Due to the nature of several issues all affecting the same area,
fixing separately each issue is not practical, since each fix can not be
implemented and tested independently.
In particular, the issues with
- rule recursion
- nested case statements
- forward jump resolution (backpatch list)
are tightly coupled (see below).
Definitions
===========
The expression
CASE expr
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Simple Case Expression".
The expression
CASE
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Searched Case Expression".
The statement
CASE expr
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Simple Case Statement".
The statement
CASE
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Searched Case Statement".
A "Left Recursive" rule is like
list:
element
| list element
;
A "Right Recursive" rule is like
list:
element
| element list
;
Left and right recursion produces the same language, the difference only
affects the *order* in which the text is parsed.
In a descendant parser (usually written manually), right recursion works
very well, and is typically implemented with a while loop.
In an ascendant parser (yacc/bison) left recursion works very well,
and is implemented naturally by the parser stack.
In both cases, using the wrong type or recursion is very bad and should be
avoided, as it causes technical issues with the parser implementation.
Before this change
==================
The "Simple Case Expression" and "Searched Case Expression" were both
implemented by the "when_list" and "when_list2" rules, which are left
recursive (ok).
These rules, however, used lex->when_list instead of using the parser stack,
which is more complex that necessary, and potentially dangerous because
of other rules using THD::reset_lex.
The "Simple Case Statement" and "Searched Case Statements" were implemented
by the "sp_case", "sp_whens" and in part by "sp_proc_stmt" rules.
Both cases were right recursive (bad).
The grammar involved was convoluted, and is assumed to be the results of
tweaks to get the code generation to work, but is not what someone would
naturally write.
In addition, using a common rule for both "Simple" and "Searched" case
statements was implemented with sp_head::m_flags |= IN_SIMPLE_CASE,
which is a flag and not a stack, and therefore does not take into account
*nested* case statements. This leads to incorrect generated code, and either
a server crash or an incorrect result.
With regards to the backpatch mechanism, a *different* backpatch list was
created for each jump from "WHEN expr THEN stmt" to "END CASE", which
relied on the grammar to be right recursive.
This is a mis-use of the backpatch list, since this list can resolve
multiple references to the same target at once.
The optimizer algorithm used to detect dead code in the "assembly" SQL
instructions, implemented by sp_head::opt_mark(uint ip), was recursive
in some cases (a conditional jump pointing forward to another conditional
jump).
In case of specially crafted code, like
- a long list of "IF expr THEN stmt END IF"
- a long CASE statement
this would actually cause a server crash with a stack overflow.
In general, having a stack that grows proportionally with user data (the
SQL code given by the client in a CREATE PROCEDURE) is to be avoided.
In debug builds only, creating a SP / SF / Trigger which had a significant
amount of code would spend --literally-- several minutes in sp_head::create,
because of the debug code involved with DBUG_PRINT("info", ("Code %s ...
There are several issues with this code:
- in a CASE with 5 000 WHEN, there are 15 000 instructions generated,
which create a sting representation of the code which is 500 000 bytes
long,
- using a String instead of an io stream causes performances to degrade
to a total server freeze, as time is spent doing realloc of a buffer
always too short,
- Printing a 500 000 long string in the debug log is too verbose,
- Generating this string even when DBUG_PRINT is off is useless,
- Having code that potentially can affect the server behavior, used with
#ifdef / #endif is useful in some cases, but is also a bad practice.
After this change
=================
"Case Expressions" (both simple and searched) have been simplified to
not use LEX::when_list, which has been removed.
Considering all the issues affecting case statements, the grammar for these
has been totally re written.
The existing actions, used to generate "assembly" sp_inst* code, have been
preserved but moved in the new grammar, with the following changes:
a) Bison rules are no longer shared between "Simple" and "Searched" case
statements, because a stack instead of a flag is required to handle them.
Nested statements are handled naturally by the parser stack, which by
definition uses the correct rule in the correct context.
Nested statements of the opposite type (simple vs searched) works correctly.
The flag sp_head::IN_SIMPLE_CASE is no longer used.
This is a step towards resolution of WL#2999, which correctly identified
that temporary parsing flags do not belong to sp_head.
The code in the action is shared by mean of the case_stmt_action_xxx()
helpers.
b) The backpatch mechanism, used to resolve forward jumps in the generated
code, has been changed to:
- create a label for the instruction following 'END CASE',
- register each jump at the end of a "WHEN expr THEN stmt" in a *unique*
backpatch list associated with the 'END CASE' label
- resolve all the forward jumps for this label at once.
In addition, the code involving backpatch has been commented, so that a
reader can now understand by reading matching "Registering" and "Resolving"
comments how the forward jumps are resolved and what target they resolve to,
as this is far from evident when reading the code alone.
The implementation of sp_head::opt_mark() has been revised to avoid
recursive calls from jump instructions, and instead add the jump location
to the list of paths to explore during the flow analysis of the instruction
graph, with a call to sp_head::add_mark_lead().
In addition, the flow analysis will stop if an instruction has already
been marked as reachable, which the previous code failed to do in the
recursive case.
sp_head::opt_mark() is now private, to prevent new calls to this method from
being introduced.
The debug code present in sp_head::create() has been removed.
Considering that SHOW PROCEDURE CODE is also available in debug builds,
and can be used anytime regardless of the trace level, as opposed to
"CREATE PROCEDURE" time and only if the trace was on,
removing the code actually makes debugging easier (usable trace).
Tests have been written to cover the parser overflow (big CASE),
and to cover nested CASE statements.
2006-11-17 20:14:29 +01:00
|
|
|
virtual uint opt_mark(sp_head *sp, List<sp_instr> *leads);
|
2004-08-02 18:05:31 +02:00
|
|
|
|
2006-01-25 15:11:49 +01:00
|
|
|
/* Override sp_instr_jump's shortcut; we stop here */
|
2004-08-26 12:54:30 +02:00
|
|
|
virtual uint opt_shortcut_jump(sp_head *sp, sp_instr *start)
|
2004-08-02 18:05:31 +02:00
|
|
|
{
|
|
|
|
return m_ip;
|
|
|
|
}
|
|
|
|
|
2005-11-04 15:37:39 +01:00
|
|
|
virtual void opt_move(uint dst, List<sp_instr> *ibp);
|
|
|
|
|
|
|
|
virtual void set_destination(uint old_dest, uint new_dest)
|
|
|
|
{
|
|
|
|
sp_instr_jump::set_destination(old_dest, new_dest);
|
|
|
|
if (m_cont_dest == old_dest)
|
|
|
|
m_cont_dest= new_dest;
|
|
|
|
}
|
|
|
|
|
2002-12-11 14:24:29 +01:00
|
|
|
private:
|
|
|
|
|
|
|
|
Item *m_expr; // The condition
|
2005-03-04 14:35:28 +01:00
|
|
|
sp_lex_keeper m_lex_keeper;
|
2002-12-11 14:24:29 +01:00
|
|
|
|
|
|
|
}; // class sp_instr_jump_if_not : public sp_instr_jump
|
|
|
|
|
2003-02-26 19:22:29 +01:00
|
|
|
|
2003-09-16 14:26:08 +02:00
|
|
|
class sp_instr_freturn : public sp_instr
|
2003-02-26 19:22:29 +01:00
|
|
|
{
|
2003-09-16 14:26:08 +02:00
|
|
|
sp_instr_freturn(const sp_instr_freturn &); /* Prevent use of these */
|
|
|
|
void operator=(sp_instr_freturn &);
|
2003-02-26 19:22:29 +01:00
|
|
|
|
|
|
|
public:
|
|
|
|
|
2004-08-26 12:54:30 +02:00
|
|
|
sp_instr_freturn(uint ip, sp_pcontext *ctx,
|
2006-12-14 23:51:37 +01:00
|
|
|
Item *val, enum enum_field_types type_arg, LEX *lex)
|
|
|
|
: sp_instr(ip, ctx), m_value(val), m_type(type_arg),
|
|
|
|
m_lex_keeper(lex, TRUE)
|
2003-02-26 19:22:29 +01:00
|
|
|
{}
|
|
|
|
|
2003-09-16 14:26:08 +02:00
|
|
|
virtual ~sp_instr_freturn()
|
2003-02-26 19:22:29 +01:00
|
|
|
{}
|
|
|
|
|
|
|
|
virtual int execute(THD *thd, uint *nextp);
|
|
|
|
|
2005-03-04 14:35:28 +01:00
|
|
|
virtual int exec_core(THD *thd, uint *nextp);
|
|
|
|
|
2004-03-29 11:16:45 +02:00
|
|
|
virtual void print(String *str);
|
|
|
|
|
Bug#19194 (Right recursion in parser for CASE causes excessive stack usage,
limitation)
Note to the reviewer
====================
Warning: reviewing this patch is somewhat involved.
Due to the nature of several issues all affecting the same area,
fixing separately each issue is not practical, since each fix can not be
implemented and tested independently.
In particular, the issues with
- rule recursion
- nested case statements
- forward jump resolution (backpatch list)
are tightly coupled (see below).
Definitions
===========
The expression
CASE expr
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Simple Case Expression".
The expression
CASE
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Searched Case Expression".
The statement
CASE expr
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Simple Case Statement".
The statement
CASE
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Searched Case Statement".
A "Left Recursive" rule is like
list:
element
| list element
;
A "Right Recursive" rule is like
list:
element
| element list
;
Left and right recursion produces the same language, the difference only
affects the *order* in which the text is parsed.
In a descendant parser (usually written manually), right recursion works
very well, and is typically implemented with a while loop.
In an ascendant parser (yacc/bison) left recursion works very well,
and is implemented naturally by the parser stack.
In both cases, using the wrong type or recursion is very bad and should be
avoided, as it causes technical issues with the parser implementation.
Before this change
==================
The "Simple Case Expression" and "Searched Case Expression" were both
implemented by the "when_list" and "when_list2" rules, which are left
recursive (ok).
These rules, however, used lex->when_list instead of using the parser stack,
which is more complex that necessary, and potentially dangerous because
of other rules using THD::reset_lex.
The "Simple Case Statement" and "Searched Case Statements" were implemented
by the "sp_case", "sp_whens" and in part by "sp_proc_stmt" rules.
Both cases were right recursive (bad).
The grammar involved was convoluted, and is assumed to be the results of
tweaks to get the code generation to work, but is not what someone would
naturally write.
In addition, using a common rule for both "Simple" and "Searched" case
statements was implemented with sp_head::m_flags |= IN_SIMPLE_CASE,
which is a flag and not a stack, and therefore does not take into account
*nested* case statements. This leads to incorrect generated code, and either
a server crash or an incorrect result.
With regards to the backpatch mechanism, a *different* backpatch list was
created for each jump from "WHEN expr THEN stmt" to "END CASE", which
relied on the grammar to be right recursive.
This is a mis-use of the backpatch list, since this list can resolve
multiple references to the same target at once.
The optimizer algorithm used to detect dead code in the "assembly" SQL
instructions, implemented by sp_head::opt_mark(uint ip), was recursive
in some cases (a conditional jump pointing forward to another conditional
jump).
In case of specially crafted code, like
- a long list of "IF expr THEN stmt END IF"
- a long CASE statement
this would actually cause a server crash with a stack overflow.
In general, having a stack that grows proportionally with user data (the
SQL code given by the client in a CREATE PROCEDURE) is to be avoided.
In debug builds only, creating a SP / SF / Trigger which had a significant
amount of code would spend --literally-- several minutes in sp_head::create,
because of the debug code involved with DBUG_PRINT("info", ("Code %s ...
There are several issues with this code:
- in a CASE with 5 000 WHEN, there are 15 000 instructions generated,
which create a sting representation of the code which is 500 000 bytes
long,
- using a String instead of an io stream causes performances to degrade
to a total server freeze, as time is spent doing realloc of a buffer
always too short,
- Printing a 500 000 long string in the debug log is too verbose,
- Generating this string even when DBUG_PRINT is off is useless,
- Having code that potentially can affect the server behavior, used with
#ifdef / #endif is useful in some cases, but is also a bad practice.
After this change
=================
"Case Expressions" (both simple and searched) have been simplified to
not use LEX::when_list, which has been removed.
Considering all the issues affecting case statements, the grammar for these
has been totally re written.
The existing actions, used to generate "assembly" sp_inst* code, have been
preserved but moved in the new grammar, with the following changes:
a) Bison rules are no longer shared between "Simple" and "Searched" case
statements, because a stack instead of a flag is required to handle them.
Nested statements are handled naturally by the parser stack, which by
definition uses the correct rule in the correct context.
Nested statements of the opposite type (simple vs searched) works correctly.
The flag sp_head::IN_SIMPLE_CASE is no longer used.
This is a step towards resolution of WL#2999, which correctly identified
that temporary parsing flags do not belong to sp_head.
The code in the action is shared by mean of the case_stmt_action_xxx()
helpers.
b) The backpatch mechanism, used to resolve forward jumps in the generated
code, has been changed to:
- create a label for the instruction following 'END CASE',
- register each jump at the end of a "WHEN expr THEN stmt" in a *unique*
backpatch list associated with the 'END CASE' label
- resolve all the forward jumps for this label at once.
In addition, the code involving backpatch has been commented, so that a
reader can now understand by reading matching "Registering" and "Resolving"
comments how the forward jumps are resolved and what target they resolve to,
as this is far from evident when reading the code alone.
The implementation of sp_head::opt_mark() has been revised to avoid
recursive calls from jump instructions, and instead add the jump location
to the list of paths to explore during the flow analysis of the instruction
graph, with a call to sp_head::add_mark_lead().
In addition, the flow analysis will stop if an instruction has already
been marked as reachable, which the previous code failed to do in the
recursive case.
sp_head::opt_mark() is now private, to prevent new calls to this method from
being introduced.
The debug code present in sp_head::create() has been removed.
Considering that SHOW PROCEDURE CODE is also available in debug builds,
and can be used anytime regardless of the trace level, as opposed to
"CREATE PROCEDURE" time and only if the trace was on,
removing the code actually makes debugging easier (usable trace).
Tests have been written to cover the parser overflow (big CASE),
and to cover nested CASE statements.
2006-11-17 20:14:29 +01:00
|
|
|
virtual uint opt_mark(sp_head *sp, List<sp_instr> *leads)
|
2004-08-02 18:05:31 +02:00
|
|
|
{
|
|
|
|
marked= 1;
|
|
|
|
return UINT_MAX;
|
|
|
|
}
|
|
|
|
|
2003-02-26 19:22:29 +01:00
|
|
|
protected:
|
|
|
|
|
|
|
|
Item *m_value;
|
|
|
|
enum enum_field_types m_type;
|
2005-03-04 14:35:28 +01:00
|
|
|
sp_lex_keeper m_lex_keeper;
|
2003-02-26 19:22:29 +01:00
|
|
|
|
2003-09-16 14:26:08 +02:00
|
|
|
}; // class sp_instr_freturn : public sp_instr
|
|
|
|
|
|
|
|
|
|
|
|
class sp_instr_hpush_jump : public sp_instr_jump
|
|
|
|
{
|
|
|
|
sp_instr_hpush_jump(const sp_instr_hpush_jump &); /* Prevent use of these */
|
|
|
|
void operator=(sp_instr_hpush_jump &);
|
|
|
|
|
|
|
|
public:
|
|
|
|
|
2004-08-26 12:54:30 +02:00
|
|
|
sp_instr_hpush_jump(uint ip, sp_pcontext *ctx, int htype, uint fp)
|
|
|
|
: sp_instr_jump(ip, ctx), m_type(htype), m_frame(fp)
|
2003-09-16 14:26:08 +02:00
|
|
|
{
|
|
|
|
m_cond.empty();
|
|
|
|
}
|
|
|
|
|
|
|
|
virtual ~sp_instr_hpush_jump()
|
|
|
|
{
|
|
|
|
m_cond.empty();
|
|
|
|
}
|
|
|
|
|
|
|
|
virtual int execute(THD *thd, uint *nextp);
|
|
|
|
|
2004-03-29 11:16:45 +02:00
|
|
|
virtual void print(String *str);
|
|
|
|
|
Bug#19194 (Right recursion in parser for CASE causes excessive stack usage,
limitation)
Note to the reviewer
====================
Warning: reviewing this patch is somewhat involved.
Due to the nature of several issues all affecting the same area,
fixing separately each issue is not practical, since each fix can not be
implemented and tested independently.
In particular, the issues with
- rule recursion
- nested case statements
- forward jump resolution (backpatch list)
are tightly coupled (see below).
Definitions
===========
The expression
CASE expr
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Simple Case Expression".
The expression
CASE
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Searched Case Expression".
The statement
CASE expr
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Simple Case Statement".
The statement
CASE
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Searched Case Statement".
A "Left Recursive" rule is like
list:
element
| list element
;
A "Right Recursive" rule is like
list:
element
| element list
;
Left and right recursion produces the same language, the difference only
affects the *order* in which the text is parsed.
In a descendant parser (usually written manually), right recursion works
very well, and is typically implemented with a while loop.
In an ascendant parser (yacc/bison) left recursion works very well,
and is implemented naturally by the parser stack.
In both cases, using the wrong type or recursion is very bad and should be
avoided, as it causes technical issues with the parser implementation.
Before this change
==================
The "Simple Case Expression" and "Searched Case Expression" were both
implemented by the "when_list" and "when_list2" rules, which are left
recursive (ok).
These rules, however, used lex->when_list instead of using the parser stack,
which is more complex that necessary, and potentially dangerous because
of other rules using THD::reset_lex.
The "Simple Case Statement" and "Searched Case Statements" were implemented
by the "sp_case", "sp_whens" and in part by "sp_proc_stmt" rules.
Both cases were right recursive (bad).
The grammar involved was convoluted, and is assumed to be the results of
tweaks to get the code generation to work, but is not what someone would
naturally write.
In addition, using a common rule for both "Simple" and "Searched" case
statements was implemented with sp_head::m_flags |= IN_SIMPLE_CASE,
which is a flag and not a stack, and therefore does not take into account
*nested* case statements. This leads to incorrect generated code, and either
a server crash or an incorrect result.
With regards to the backpatch mechanism, a *different* backpatch list was
created for each jump from "WHEN expr THEN stmt" to "END CASE", which
relied on the grammar to be right recursive.
This is a mis-use of the backpatch list, since this list can resolve
multiple references to the same target at once.
The optimizer algorithm used to detect dead code in the "assembly" SQL
instructions, implemented by sp_head::opt_mark(uint ip), was recursive
in some cases (a conditional jump pointing forward to another conditional
jump).
In case of specially crafted code, like
- a long list of "IF expr THEN stmt END IF"
- a long CASE statement
this would actually cause a server crash with a stack overflow.
In general, having a stack that grows proportionally with user data (the
SQL code given by the client in a CREATE PROCEDURE) is to be avoided.
In debug builds only, creating a SP / SF / Trigger which had a significant
amount of code would spend --literally-- several minutes in sp_head::create,
because of the debug code involved with DBUG_PRINT("info", ("Code %s ...
There are several issues with this code:
- in a CASE with 5 000 WHEN, there are 15 000 instructions generated,
which create a sting representation of the code which is 500 000 bytes
long,
- using a String instead of an io stream causes performances to degrade
to a total server freeze, as time is spent doing realloc of a buffer
always too short,
- Printing a 500 000 long string in the debug log is too verbose,
- Generating this string even when DBUG_PRINT is off is useless,
- Having code that potentially can affect the server behavior, used with
#ifdef / #endif is useful in some cases, but is also a bad practice.
After this change
=================
"Case Expressions" (both simple and searched) have been simplified to
not use LEX::when_list, which has been removed.
Considering all the issues affecting case statements, the grammar for these
has been totally re written.
The existing actions, used to generate "assembly" sp_inst* code, have been
preserved but moved in the new grammar, with the following changes:
a) Bison rules are no longer shared between "Simple" and "Searched" case
statements, because a stack instead of a flag is required to handle them.
Nested statements are handled naturally by the parser stack, which by
definition uses the correct rule in the correct context.
Nested statements of the opposite type (simple vs searched) works correctly.
The flag sp_head::IN_SIMPLE_CASE is no longer used.
This is a step towards resolution of WL#2999, which correctly identified
that temporary parsing flags do not belong to sp_head.
The code in the action is shared by mean of the case_stmt_action_xxx()
helpers.
b) The backpatch mechanism, used to resolve forward jumps in the generated
code, has been changed to:
- create a label for the instruction following 'END CASE',
- register each jump at the end of a "WHEN expr THEN stmt" in a *unique*
backpatch list associated with the 'END CASE' label
- resolve all the forward jumps for this label at once.
In addition, the code involving backpatch has been commented, so that a
reader can now understand by reading matching "Registering" and "Resolving"
comments how the forward jumps are resolved and what target they resolve to,
as this is far from evident when reading the code alone.
The implementation of sp_head::opt_mark() has been revised to avoid
recursive calls from jump instructions, and instead add the jump location
to the list of paths to explore during the flow analysis of the instruction
graph, with a call to sp_head::add_mark_lead().
In addition, the flow analysis will stop if an instruction has already
been marked as reachable, which the previous code failed to do in the
recursive case.
sp_head::opt_mark() is now private, to prevent new calls to this method from
being introduced.
The debug code present in sp_head::create() has been removed.
Considering that SHOW PROCEDURE CODE is also available in debug builds,
and can be used anytime regardless of the trace level, as opposed to
"CREATE PROCEDURE" time and only if the trace was on,
removing the code actually makes debugging easier (usable trace).
Tests have been written to cover the parser overflow (big CASE),
and to cover nested CASE statements.
2006-11-17 20:14:29 +01:00
|
|
|
virtual uint opt_mark(sp_head *sp, List<sp_instr> *leads);
|
2004-08-02 18:05:31 +02:00
|
|
|
|
2006-01-25 15:11:49 +01:00
|
|
|
/* Override sp_instr_jump's shortcut; we stop here. */
|
2004-08-26 12:54:30 +02:00
|
|
|
virtual uint opt_shortcut_jump(sp_head *sp, sp_instr *start)
|
2004-08-02 18:05:31 +02:00
|
|
|
{
|
|
|
|
return m_ip;
|
|
|
|
}
|
|
|
|
|
2003-09-16 14:26:08 +02:00
|
|
|
inline void add_condition(struct sp_cond_type *cond)
|
|
|
|
{
|
|
|
|
m_cond.push_front(cond);
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
|
|
|
int m_type; // Handler type
|
|
|
|
uint m_frame;
|
|
|
|
List<struct sp_cond_type> m_cond;
|
|
|
|
|
|
|
|
}; // class sp_instr_hpush_jump : public sp_instr_jump
|
|
|
|
|
|
|
|
|
|
|
|
class sp_instr_hpop : public sp_instr
|
|
|
|
{
|
|
|
|
sp_instr_hpop(const sp_instr_hpop &); /* Prevent use of these */
|
|
|
|
void operator=(sp_instr_hpop &);
|
|
|
|
|
|
|
|
public:
|
|
|
|
|
2004-08-26 12:54:30 +02:00
|
|
|
sp_instr_hpop(uint ip, sp_pcontext *ctx, uint count)
|
|
|
|
: sp_instr(ip, ctx), m_count(count)
|
2003-09-16 14:26:08 +02:00
|
|
|
{}
|
|
|
|
|
|
|
|
virtual ~sp_instr_hpop()
|
|
|
|
{}
|
|
|
|
|
|
|
|
virtual int execute(THD *thd, uint *nextp);
|
|
|
|
|
2004-03-29 11:16:45 +02:00
|
|
|
virtual void print(String *str);
|
|
|
|
|
2003-09-16 14:26:08 +02:00
|
|
|
private:
|
|
|
|
|
|
|
|
uint m_count;
|
|
|
|
|
|
|
|
}; // class sp_instr_hpop : public sp_instr
|
|
|
|
|
|
|
|
|
2004-09-10 11:11:52 +02:00
|
|
|
class sp_instr_hreturn : public sp_instr_jump
|
2003-09-16 14:26:08 +02:00
|
|
|
{
|
|
|
|
sp_instr_hreturn(const sp_instr_hreturn &); /* Prevent use of these */
|
|
|
|
void operator=(sp_instr_hreturn &);
|
|
|
|
|
|
|
|
public:
|
|
|
|
|
2004-08-26 12:54:30 +02:00
|
|
|
sp_instr_hreturn(uint ip, sp_pcontext *ctx, uint fp)
|
2004-09-10 11:11:52 +02:00
|
|
|
: sp_instr_jump(ip, ctx), m_frame(fp)
|
2003-09-16 14:26:08 +02:00
|
|
|
{}
|
|
|
|
|
|
|
|
virtual ~sp_instr_hreturn()
|
|
|
|
{}
|
|
|
|
|
|
|
|
virtual int execute(THD *thd, uint *nextp);
|
|
|
|
|
2004-03-29 11:16:45 +02:00
|
|
|
virtual void print(String *str);
|
|
|
|
|
2007-05-07 10:23:10 +02:00
|
|
|
/* This instruction will not be short cut optimized. */
|
|
|
|
virtual uint opt_shortcut_jump(sp_head *sp, sp_instr *start)
|
|
|
|
{
|
|
|
|
return m_ip;
|
|
|
|
}
|
|
|
|
|
Bug#19194 (Right recursion in parser for CASE causes excessive stack usage,
limitation)
Note to the reviewer
====================
Warning: reviewing this patch is somewhat involved.
Due to the nature of several issues all affecting the same area,
fixing separately each issue is not practical, since each fix can not be
implemented and tested independently.
In particular, the issues with
- rule recursion
- nested case statements
- forward jump resolution (backpatch list)
are tightly coupled (see below).
Definitions
===========
The expression
CASE expr
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Simple Case Expression".
The expression
CASE
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Searched Case Expression".
The statement
CASE expr
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Simple Case Statement".
The statement
CASE
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Searched Case Statement".
A "Left Recursive" rule is like
list:
element
| list element
;
A "Right Recursive" rule is like
list:
element
| element list
;
Left and right recursion produces the same language, the difference only
affects the *order* in which the text is parsed.
In a descendant parser (usually written manually), right recursion works
very well, and is typically implemented with a while loop.
In an ascendant parser (yacc/bison) left recursion works very well,
and is implemented naturally by the parser stack.
In both cases, using the wrong type or recursion is very bad and should be
avoided, as it causes technical issues with the parser implementation.
Before this change
==================
The "Simple Case Expression" and "Searched Case Expression" were both
implemented by the "when_list" and "when_list2" rules, which are left
recursive (ok).
These rules, however, used lex->when_list instead of using the parser stack,
which is more complex that necessary, and potentially dangerous because
of other rules using THD::reset_lex.
The "Simple Case Statement" and "Searched Case Statements" were implemented
by the "sp_case", "sp_whens" and in part by "sp_proc_stmt" rules.
Both cases were right recursive (bad).
The grammar involved was convoluted, and is assumed to be the results of
tweaks to get the code generation to work, but is not what someone would
naturally write.
In addition, using a common rule for both "Simple" and "Searched" case
statements was implemented with sp_head::m_flags |= IN_SIMPLE_CASE,
which is a flag and not a stack, and therefore does not take into account
*nested* case statements. This leads to incorrect generated code, and either
a server crash or an incorrect result.
With regards to the backpatch mechanism, a *different* backpatch list was
created for each jump from "WHEN expr THEN stmt" to "END CASE", which
relied on the grammar to be right recursive.
This is a mis-use of the backpatch list, since this list can resolve
multiple references to the same target at once.
The optimizer algorithm used to detect dead code in the "assembly" SQL
instructions, implemented by sp_head::opt_mark(uint ip), was recursive
in some cases (a conditional jump pointing forward to another conditional
jump).
In case of specially crafted code, like
- a long list of "IF expr THEN stmt END IF"
- a long CASE statement
this would actually cause a server crash with a stack overflow.
In general, having a stack that grows proportionally with user data (the
SQL code given by the client in a CREATE PROCEDURE) is to be avoided.
In debug builds only, creating a SP / SF / Trigger which had a significant
amount of code would spend --literally-- several minutes in sp_head::create,
because of the debug code involved with DBUG_PRINT("info", ("Code %s ...
There are several issues with this code:
- in a CASE with 5 000 WHEN, there are 15 000 instructions generated,
which create a sting representation of the code which is 500 000 bytes
long,
- using a String instead of an io stream causes performances to degrade
to a total server freeze, as time is spent doing realloc of a buffer
always too short,
- Printing a 500 000 long string in the debug log is too verbose,
- Generating this string even when DBUG_PRINT is off is useless,
- Having code that potentially can affect the server behavior, used with
#ifdef / #endif is useful in some cases, but is also a bad practice.
After this change
=================
"Case Expressions" (both simple and searched) have been simplified to
not use LEX::when_list, which has been removed.
Considering all the issues affecting case statements, the grammar for these
has been totally re written.
The existing actions, used to generate "assembly" sp_inst* code, have been
preserved but moved in the new grammar, with the following changes:
a) Bison rules are no longer shared between "Simple" and "Searched" case
statements, because a stack instead of a flag is required to handle them.
Nested statements are handled naturally by the parser stack, which by
definition uses the correct rule in the correct context.
Nested statements of the opposite type (simple vs searched) works correctly.
The flag sp_head::IN_SIMPLE_CASE is no longer used.
This is a step towards resolution of WL#2999, which correctly identified
that temporary parsing flags do not belong to sp_head.
The code in the action is shared by mean of the case_stmt_action_xxx()
helpers.
b) The backpatch mechanism, used to resolve forward jumps in the generated
code, has been changed to:
- create a label for the instruction following 'END CASE',
- register each jump at the end of a "WHEN expr THEN stmt" in a *unique*
backpatch list associated with the 'END CASE' label
- resolve all the forward jumps for this label at once.
In addition, the code involving backpatch has been commented, so that a
reader can now understand by reading matching "Registering" and "Resolving"
comments how the forward jumps are resolved and what target they resolve to,
as this is far from evident when reading the code alone.
The implementation of sp_head::opt_mark() has been revised to avoid
recursive calls from jump instructions, and instead add the jump location
to the list of paths to explore during the flow analysis of the instruction
graph, with a call to sp_head::add_mark_lead().
In addition, the flow analysis will stop if an instruction has already
been marked as reachable, which the previous code failed to do in the
recursive case.
sp_head::opt_mark() is now private, to prevent new calls to this method from
being introduced.
The debug code present in sp_head::create() has been removed.
Considering that SHOW PROCEDURE CODE is also available in debug builds,
and can be used anytime regardless of the trace level, as opposed to
"CREATE PROCEDURE" time and only if the trace was on,
removing the code actually makes debugging easier (usable trace).
Tests have been written to cover the parser overflow (big CASE),
and to cover nested CASE statements.
2006-11-17 20:14:29 +01:00
|
|
|
virtual uint opt_mark(sp_head *sp, List<sp_instr> *leads);
|
2004-08-02 18:05:31 +02:00
|
|
|
|
2003-09-16 14:26:08 +02:00
|
|
|
private:
|
|
|
|
|
|
|
|
uint m_frame;
|
|
|
|
|
2006-01-26 17:26:25 +01:00
|
|
|
}; // class sp_instr_hreturn : public sp_instr_jump
|
2003-09-16 14:26:08 +02:00
|
|
|
|
2003-02-26 19:22:29 +01:00
|
|
|
|
2005-08-25 15:34:34 +02:00
|
|
|
/* This is DECLARE CURSOR */
|
2003-10-10 16:57:21 +02:00
|
|
|
class sp_instr_cpush : public sp_instr
|
|
|
|
{
|
|
|
|
sp_instr_cpush(const sp_instr_cpush &); /* Prevent use of these */
|
|
|
|
void operator=(sp_instr_cpush &);
|
|
|
|
|
|
|
|
public:
|
|
|
|
|
2005-11-17 11:11:48 +01:00
|
|
|
sp_instr_cpush(uint ip, sp_pcontext *ctx, LEX *lex, uint offset)
|
|
|
|
: sp_instr(ip, ctx), m_lex_keeper(lex, TRUE), m_cursor(offset)
|
2003-10-10 16:57:21 +02:00
|
|
|
{}
|
|
|
|
|
2005-03-04 14:35:28 +01:00
|
|
|
virtual ~sp_instr_cpush()
|
|
|
|
{}
|
2003-10-10 16:57:21 +02:00
|
|
|
|
|
|
|
virtual int execute(THD *thd, uint *nextp);
|
|
|
|
|
2004-03-29 11:16:45 +02:00
|
|
|
virtual void print(String *str);
|
|
|
|
|
2005-09-22 00:11:21 +02:00
|
|
|
/*
|
|
|
|
This call is used to cleanup the instruction when a sensitive
|
|
|
|
cursor is closed. For now stored procedures always use materialized
|
|
|
|
cursors and the call is not used.
|
|
|
|
*/
|
|
|
|
virtual void cleanup_stmt() { /* no op */ }
|
2003-10-10 16:57:21 +02:00
|
|
|
private:
|
|
|
|
|
2005-03-04 14:35:28 +01:00
|
|
|
sp_lex_keeper m_lex_keeper;
|
2005-11-17 11:11:48 +01:00
|
|
|
uint m_cursor; /* Frame offset (for debugging) */
|
2003-10-10 16:57:21 +02:00
|
|
|
|
|
|
|
}; // class sp_instr_cpush : public sp_instr
|
|
|
|
|
|
|
|
|
|
|
|
class sp_instr_cpop : public sp_instr
|
|
|
|
{
|
|
|
|
sp_instr_cpop(const sp_instr_cpop &); /* Prevent use of these */
|
|
|
|
void operator=(sp_instr_cpop &);
|
|
|
|
|
|
|
|
public:
|
|
|
|
|
2004-08-26 12:54:30 +02:00
|
|
|
sp_instr_cpop(uint ip, sp_pcontext *ctx, uint count)
|
|
|
|
: sp_instr(ip, ctx), m_count(count)
|
2003-10-10 16:57:21 +02:00
|
|
|
{}
|
|
|
|
|
|
|
|
virtual ~sp_instr_cpop()
|
|
|
|
{}
|
|
|
|
|
|
|
|
virtual int execute(THD *thd, uint *nextp);
|
|
|
|
|
2004-03-29 11:16:45 +02:00
|
|
|
virtual void print(String *str);
|
|
|
|
|
2003-10-10 16:57:21 +02:00
|
|
|
private:
|
|
|
|
|
|
|
|
uint m_count;
|
|
|
|
|
|
|
|
}; // class sp_instr_cpop : public sp_instr
|
|
|
|
|
|
|
|
|
2005-03-04 14:35:28 +01:00
|
|
|
class sp_instr_copen : public sp_instr
|
2003-10-10 16:57:21 +02:00
|
|
|
{
|
|
|
|
sp_instr_copen(const sp_instr_copen &); /* Prevent use of these */
|
|
|
|
void operator=(sp_instr_copen &);
|
|
|
|
|
|
|
|
public:
|
|
|
|
|
2004-08-26 12:54:30 +02:00
|
|
|
sp_instr_copen(uint ip, sp_pcontext *ctx, uint c)
|
2005-03-04 14:35:28 +01:00
|
|
|
: sp_instr(ip, ctx), m_cursor(c)
|
2003-10-10 16:57:21 +02:00
|
|
|
{}
|
|
|
|
|
|
|
|
virtual ~sp_instr_copen()
|
|
|
|
{}
|
|
|
|
|
|
|
|
virtual int execute(THD *thd, uint *nextp);
|
|
|
|
|
2005-03-04 14:35:28 +01:00
|
|
|
virtual int exec_core(THD *thd, uint *nextp);
|
|
|
|
|
2004-03-29 11:16:45 +02:00
|
|
|
virtual void print(String *str);
|
|
|
|
|
2003-10-10 16:57:21 +02:00
|
|
|
private:
|
|
|
|
|
|
|
|
uint m_cursor; // Stack index
|
|
|
|
|
|
|
|
}; // class sp_instr_copen : public sp_instr_stmt
|
|
|
|
|
|
|
|
|
|
|
|
class sp_instr_cclose : public sp_instr
|
|
|
|
{
|
|
|
|
sp_instr_cclose(const sp_instr_cclose &); /* Prevent use of these */
|
|
|
|
void operator=(sp_instr_cclose &);
|
|
|
|
|
|
|
|
public:
|
|
|
|
|
2004-08-26 12:54:30 +02:00
|
|
|
sp_instr_cclose(uint ip, sp_pcontext *ctx, uint c)
|
|
|
|
: sp_instr(ip, ctx), m_cursor(c)
|
2003-10-10 16:57:21 +02:00
|
|
|
{}
|
|
|
|
|
|
|
|
virtual ~sp_instr_cclose()
|
|
|
|
{}
|
|
|
|
|
|
|
|
virtual int execute(THD *thd, uint *nextp);
|
|
|
|
|
2004-03-29 11:16:45 +02:00
|
|
|
virtual void print(String *str);
|
|
|
|
|
2003-10-10 16:57:21 +02:00
|
|
|
private:
|
|
|
|
|
|
|
|
uint m_cursor;
|
|
|
|
|
|
|
|
}; // class sp_instr_cclose : public sp_instr
|
|
|
|
|
|
|
|
|
|
|
|
class sp_instr_cfetch : public sp_instr
|
|
|
|
{
|
|
|
|
sp_instr_cfetch(const sp_instr_cfetch &); /* Prevent use of these */
|
|
|
|
void operator=(sp_instr_cfetch &);
|
|
|
|
|
|
|
|
public:
|
|
|
|
|
2004-08-26 12:54:30 +02:00
|
|
|
sp_instr_cfetch(uint ip, sp_pcontext *ctx, uint c)
|
|
|
|
: sp_instr(ip, ctx), m_cursor(c)
|
2003-10-10 16:57:21 +02:00
|
|
|
{
|
|
|
|
m_varlist.empty();
|
|
|
|
}
|
|
|
|
|
|
|
|
virtual ~sp_instr_cfetch()
|
|
|
|
{}
|
|
|
|
|
|
|
|
virtual int execute(THD *thd, uint *nextp);
|
|
|
|
|
2004-03-29 11:16:45 +02:00
|
|
|
virtual void print(String *str);
|
|
|
|
|
2006-04-07 16:53:15 +02:00
|
|
|
void add_to_varlist(struct sp_variable *var)
|
2003-10-10 16:57:21 +02:00
|
|
|
{
|
|
|
|
m_varlist.push_back(var);
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
|
|
|
uint m_cursor;
|
2006-04-07 16:53:15 +02:00
|
|
|
List<struct sp_variable> m_varlist;
|
2003-10-10 16:57:21 +02:00
|
|
|
|
|
|
|
}; // class sp_instr_cfetch : public sp_instr
|
|
|
|
|
|
|
|
|
2004-03-29 11:16:45 +02:00
|
|
|
class sp_instr_error : public sp_instr
|
|
|
|
{
|
|
|
|
sp_instr_error(const sp_instr_error &); /* Prevent use of these */
|
|
|
|
void operator=(sp_instr_error &);
|
|
|
|
|
|
|
|
public:
|
|
|
|
|
2004-08-26 12:54:30 +02:00
|
|
|
sp_instr_error(uint ip, sp_pcontext *ctx, int errcode)
|
|
|
|
: sp_instr(ip, ctx), m_errcode(errcode)
|
2004-03-29 11:16:45 +02:00
|
|
|
{}
|
|
|
|
|
|
|
|
virtual ~sp_instr_error()
|
|
|
|
{}
|
|
|
|
|
|
|
|
virtual int execute(THD *thd, uint *nextp);
|
|
|
|
|
|
|
|
virtual void print(String *str);
|
|
|
|
|
Bug#19194 (Right recursion in parser for CASE causes excessive stack usage,
limitation)
Note to the reviewer
====================
Warning: reviewing this patch is somewhat involved.
Due to the nature of several issues all affecting the same area,
fixing separately each issue is not practical, since each fix can not be
implemented and tested independently.
In particular, the issues with
- rule recursion
- nested case statements
- forward jump resolution (backpatch list)
are tightly coupled (see below).
Definitions
===========
The expression
CASE expr
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Simple Case Expression".
The expression
CASE
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Searched Case Expression".
The statement
CASE expr
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Simple Case Statement".
The statement
CASE
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Searched Case Statement".
A "Left Recursive" rule is like
list:
element
| list element
;
A "Right Recursive" rule is like
list:
element
| element list
;
Left and right recursion produces the same language, the difference only
affects the *order* in which the text is parsed.
In a descendant parser (usually written manually), right recursion works
very well, and is typically implemented with a while loop.
In an ascendant parser (yacc/bison) left recursion works very well,
and is implemented naturally by the parser stack.
In both cases, using the wrong type or recursion is very bad and should be
avoided, as it causes technical issues with the parser implementation.
Before this change
==================
The "Simple Case Expression" and "Searched Case Expression" were both
implemented by the "when_list" and "when_list2" rules, which are left
recursive (ok).
These rules, however, used lex->when_list instead of using the parser stack,
which is more complex that necessary, and potentially dangerous because
of other rules using THD::reset_lex.
The "Simple Case Statement" and "Searched Case Statements" were implemented
by the "sp_case", "sp_whens" and in part by "sp_proc_stmt" rules.
Both cases were right recursive (bad).
The grammar involved was convoluted, and is assumed to be the results of
tweaks to get the code generation to work, but is not what someone would
naturally write.
In addition, using a common rule for both "Simple" and "Searched" case
statements was implemented with sp_head::m_flags |= IN_SIMPLE_CASE,
which is a flag and not a stack, and therefore does not take into account
*nested* case statements. This leads to incorrect generated code, and either
a server crash or an incorrect result.
With regards to the backpatch mechanism, a *different* backpatch list was
created for each jump from "WHEN expr THEN stmt" to "END CASE", which
relied on the grammar to be right recursive.
This is a mis-use of the backpatch list, since this list can resolve
multiple references to the same target at once.
The optimizer algorithm used to detect dead code in the "assembly" SQL
instructions, implemented by sp_head::opt_mark(uint ip), was recursive
in some cases (a conditional jump pointing forward to another conditional
jump).
In case of specially crafted code, like
- a long list of "IF expr THEN stmt END IF"
- a long CASE statement
this would actually cause a server crash with a stack overflow.
In general, having a stack that grows proportionally with user data (the
SQL code given by the client in a CREATE PROCEDURE) is to be avoided.
In debug builds only, creating a SP / SF / Trigger which had a significant
amount of code would spend --literally-- several minutes in sp_head::create,
because of the debug code involved with DBUG_PRINT("info", ("Code %s ...
There are several issues with this code:
- in a CASE with 5 000 WHEN, there are 15 000 instructions generated,
which create a sting representation of the code which is 500 000 bytes
long,
- using a String instead of an io stream causes performances to degrade
to a total server freeze, as time is spent doing realloc of a buffer
always too short,
- Printing a 500 000 long string in the debug log is too verbose,
- Generating this string even when DBUG_PRINT is off is useless,
- Having code that potentially can affect the server behavior, used with
#ifdef / #endif is useful in some cases, but is also a bad practice.
After this change
=================
"Case Expressions" (both simple and searched) have been simplified to
not use LEX::when_list, which has been removed.
Considering all the issues affecting case statements, the grammar for these
has been totally re written.
The existing actions, used to generate "assembly" sp_inst* code, have been
preserved but moved in the new grammar, with the following changes:
a) Bison rules are no longer shared between "Simple" and "Searched" case
statements, because a stack instead of a flag is required to handle them.
Nested statements are handled naturally by the parser stack, which by
definition uses the correct rule in the correct context.
Nested statements of the opposite type (simple vs searched) works correctly.
The flag sp_head::IN_SIMPLE_CASE is no longer used.
This is a step towards resolution of WL#2999, which correctly identified
that temporary parsing flags do not belong to sp_head.
The code in the action is shared by mean of the case_stmt_action_xxx()
helpers.
b) The backpatch mechanism, used to resolve forward jumps in the generated
code, has been changed to:
- create a label for the instruction following 'END CASE',
- register each jump at the end of a "WHEN expr THEN stmt" in a *unique*
backpatch list associated with the 'END CASE' label
- resolve all the forward jumps for this label at once.
In addition, the code involving backpatch has been commented, so that a
reader can now understand by reading matching "Registering" and "Resolving"
comments how the forward jumps are resolved and what target they resolve to,
as this is far from evident when reading the code alone.
The implementation of sp_head::opt_mark() has been revised to avoid
recursive calls from jump instructions, and instead add the jump location
to the list of paths to explore during the flow analysis of the instruction
graph, with a call to sp_head::add_mark_lead().
In addition, the flow analysis will stop if an instruction has already
been marked as reachable, which the previous code failed to do in the
recursive case.
sp_head::opt_mark() is now private, to prevent new calls to this method from
being introduced.
The debug code present in sp_head::create() has been removed.
Considering that SHOW PROCEDURE CODE is also available in debug builds,
and can be used anytime regardless of the trace level, as opposed to
"CREATE PROCEDURE" time and only if the trace was on,
removing the code actually makes debugging easier (usable trace).
Tests have been written to cover the parser overflow (big CASE),
and to cover nested CASE statements.
2006-11-17 20:14:29 +01:00
|
|
|
virtual uint opt_mark(sp_head *sp, List<sp_instr> *leads)
|
2004-08-02 18:05:31 +02:00
|
|
|
{
|
|
|
|
marked= 1;
|
|
|
|
return UINT_MAX;
|
|
|
|
}
|
|
|
|
|
2004-03-29 11:16:45 +02:00
|
|
|
private:
|
|
|
|
|
|
|
|
int m_errcode;
|
|
|
|
|
|
|
|
}; // class sp_instr_error : public sp_instr
|
|
|
|
|
|
|
|
|
2006-01-26 17:26:25 +01:00
|
|
|
class sp_instr_set_case_expr : public sp_instr_opt_meta
|
2005-12-07 15:01:17 +01:00
|
|
|
{
|
|
|
|
public:
|
|
|
|
|
|
|
|
sp_instr_set_case_expr(uint ip, sp_pcontext *ctx, uint case_expr_id,
|
|
|
|
Item *case_expr, LEX *lex)
|
2006-01-26 17:26:25 +01:00
|
|
|
: sp_instr_opt_meta(ip, ctx),
|
|
|
|
m_case_expr_id(case_expr_id), m_case_expr(case_expr),
|
|
|
|
m_lex_keeper(lex, TRUE)
|
|
|
|
{}
|
|
|
|
|
|
|
|
virtual ~sp_instr_set_case_expr()
|
2005-12-07 15:01:17 +01:00
|
|
|
{}
|
|
|
|
|
|
|
|
virtual int execute(THD *thd, uint *nextp);
|
|
|
|
|
|
|
|
virtual int exec_core(THD *thd, uint *nextp);
|
|
|
|
|
|
|
|
virtual void print(String *str);
|
|
|
|
|
Bug#19194 (Right recursion in parser for CASE causes excessive stack usage,
limitation)
Note to the reviewer
====================
Warning: reviewing this patch is somewhat involved.
Due to the nature of several issues all affecting the same area,
fixing separately each issue is not practical, since each fix can not be
implemented and tested independently.
In particular, the issues with
- rule recursion
- nested case statements
- forward jump resolution (backpatch list)
are tightly coupled (see below).
Definitions
===========
The expression
CASE expr
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Simple Case Expression".
The expression
CASE
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Searched Case Expression".
The statement
CASE expr
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Simple Case Statement".
The statement
CASE
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Searched Case Statement".
A "Left Recursive" rule is like
list:
element
| list element
;
A "Right Recursive" rule is like
list:
element
| element list
;
Left and right recursion produces the same language, the difference only
affects the *order* in which the text is parsed.
In a descendant parser (usually written manually), right recursion works
very well, and is typically implemented with a while loop.
In an ascendant parser (yacc/bison) left recursion works very well,
and is implemented naturally by the parser stack.
In both cases, using the wrong type or recursion is very bad and should be
avoided, as it causes technical issues with the parser implementation.
Before this change
==================
The "Simple Case Expression" and "Searched Case Expression" were both
implemented by the "when_list" and "when_list2" rules, which are left
recursive (ok).
These rules, however, used lex->when_list instead of using the parser stack,
which is more complex that necessary, and potentially dangerous because
of other rules using THD::reset_lex.
The "Simple Case Statement" and "Searched Case Statements" were implemented
by the "sp_case", "sp_whens" and in part by "sp_proc_stmt" rules.
Both cases were right recursive (bad).
The grammar involved was convoluted, and is assumed to be the results of
tweaks to get the code generation to work, but is not what someone would
naturally write.
In addition, using a common rule for both "Simple" and "Searched" case
statements was implemented with sp_head::m_flags |= IN_SIMPLE_CASE,
which is a flag and not a stack, and therefore does not take into account
*nested* case statements. This leads to incorrect generated code, and either
a server crash or an incorrect result.
With regards to the backpatch mechanism, a *different* backpatch list was
created for each jump from "WHEN expr THEN stmt" to "END CASE", which
relied on the grammar to be right recursive.
This is a mis-use of the backpatch list, since this list can resolve
multiple references to the same target at once.
The optimizer algorithm used to detect dead code in the "assembly" SQL
instructions, implemented by sp_head::opt_mark(uint ip), was recursive
in some cases (a conditional jump pointing forward to another conditional
jump).
In case of specially crafted code, like
- a long list of "IF expr THEN stmt END IF"
- a long CASE statement
this would actually cause a server crash with a stack overflow.
In general, having a stack that grows proportionally with user data (the
SQL code given by the client in a CREATE PROCEDURE) is to be avoided.
In debug builds only, creating a SP / SF / Trigger which had a significant
amount of code would spend --literally-- several minutes in sp_head::create,
because of the debug code involved with DBUG_PRINT("info", ("Code %s ...
There are several issues with this code:
- in a CASE with 5 000 WHEN, there are 15 000 instructions generated,
which create a sting representation of the code which is 500 000 bytes
long,
- using a String instead of an io stream causes performances to degrade
to a total server freeze, as time is spent doing realloc of a buffer
always too short,
- Printing a 500 000 long string in the debug log is too verbose,
- Generating this string even when DBUG_PRINT is off is useless,
- Having code that potentially can affect the server behavior, used with
#ifdef / #endif is useful in some cases, but is also a bad practice.
After this change
=================
"Case Expressions" (both simple and searched) have been simplified to
not use LEX::when_list, which has been removed.
Considering all the issues affecting case statements, the grammar for these
has been totally re written.
The existing actions, used to generate "assembly" sp_inst* code, have been
preserved but moved in the new grammar, with the following changes:
a) Bison rules are no longer shared between "Simple" and "Searched" case
statements, because a stack instead of a flag is required to handle them.
Nested statements are handled naturally by the parser stack, which by
definition uses the correct rule in the correct context.
Nested statements of the opposite type (simple vs searched) works correctly.
The flag sp_head::IN_SIMPLE_CASE is no longer used.
This is a step towards resolution of WL#2999, which correctly identified
that temporary parsing flags do not belong to sp_head.
The code in the action is shared by mean of the case_stmt_action_xxx()
helpers.
b) The backpatch mechanism, used to resolve forward jumps in the generated
code, has been changed to:
- create a label for the instruction following 'END CASE',
- register each jump at the end of a "WHEN expr THEN stmt" in a *unique*
backpatch list associated with the 'END CASE' label
- resolve all the forward jumps for this label at once.
In addition, the code involving backpatch has been commented, so that a
reader can now understand by reading matching "Registering" and "Resolving"
comments how the forward jumps are resolved and what target they resolve to,
as this is far from evident when reading the code alone.
The implementation of sp_head::opt_mark() has been revised to avoid
recursive calls from jump instructions, and instead add the jump location
to the list of paths to explore during the flow analysis of the instruction
graph, with a call to sp_head::add_mark_lead().
In addition, the flow analysis will stop if an instruction has already
been marked as reachable, which the previous code failed to do in the
recursive case.
sp_head::opt_mark() is now private, to prevent new calls to this method from
being introduced.
The debug code present in sp_head::create() has been removed.
Considering that SHOW PROCEDURE CODE is also available in debug builds,
and can be used anytime regardless of the trace level, as opposed to
"CREATE PROCEDURE" time and only if the trace was on,
removing the code actually makes debugging easier (usable trace).
Tests have been written to cover the parser overflow (big CASE),
and to cover nested CASE statements.
2006-11-17 20:14:29 +01:00
|
|
|
virtual uint opt_mark(sp_head *sp, List<sp_instr> *leads);
|
2006-01-26 17:26:25 +01:00
|
|
|
|
|
|
|
virtual void opt_move(uint dst, List<sp_instr> *ibp);
|
|
|
|
|
|
|
|
virtual void set_destination(uint old_dest, uint new_dest)
|
|
|
|
{
|
|
|
|
if (m_cont_dest == old_dest)
|
|
|
|
m_cont_dest= new_dest;
|
|
|
|
}
|
|
|
|
|
2005-12-07 15:01:17 +01:00
|
|
|
private:
|
|
|
|
|
|
|
|
uint m_case_expr_id;
|
|
|
|
Item *m_case_expr;
|
|
|
|
sp_lex_keeper m_lex_keeper;
|
|
|
|
|
2006-01-26 17:26:25 +01:00
|
|
|
}; // class sp_instr_set_case_expr : public sp_instr_opt_meta
|
2005-12-07 15:01:17 +01:00
|
|
|
|
|
|
|
|
2003-12-16 14:15:27 +01:00
|
|
|
#ifndef NO_EMBEDDED_ACCESS_CHECKS
|
2005-09-15 21:29:07 +02:00
|
|
|
bool
|
|
|
|
sp_change_security_context(THD *thd, sp_head *sp,
|
2005-09-20 20:20:38 +02:00
|
|
|
Security_context **backup);
|
2003-12-13 16:40:52 +01:00
|
|
|
void
|
2005-09-20 20:20:38 +02:00
|
|
|
sp_restore_security_context(THD *thd, Security_context *backup);
|
2006-07-13 15:12:31 +02:00
|
|
|
|
|
|
|
bool
|
|
|
|
set_routine_security_ctx(THD *thd, sp_head *sp, bool is_proc,
|
|
|
|
Security_context **save_ctx);
|
2003-12-16 14:15:27 +01:00
|
|
|
#endif /* NO_EMBEDDED_ACCESS_CHECKS */
|
2003-12-13 16:40:52 +01:00
|
|
|
|
2005-02-08 20:52:50 +01:00
|
|
|
TABLE_LIST *
|
|
|
|
sp_add_to_query_tables(THD *thd, LEX *lex,
|
|
|
|
const char *db, const char *name,
|
|
|
|
thr_lock_type locktype);
|
2005-12-07 15:01:17 +01:00
|
|
|
Item *
|
|
|
|
sp_prepare_func_item(THD* thd, Item **it_addr);
|
2005-02-08 20:52:50 +01:00
|
|
|
|
2005-12-07 15:01:17 +01:00
|
|
|
bool
|
2006-05-15 12:01:55 +02:00
|
|
|
sp_eval_expr(THD *thd, Field *result_field, Item **expr_item_ptr);
|
2005-09-22 00:11:21 +02:00
|
|
|
|
Simplistic, experimental framework for Stored Procedures (SPs).
Implements creation and dropping of PROCEDUREs, IN, OUT, and INOUT parameters,
single-statement procedures, rudimentary multi-statement (begin-end) prodedures
(when the client can handle it), and local variables.
Missing most of the embedded SQL language, all attributes, FUNCTIONs, error handling,
reparses procedures at each call (no caching), etc, etc.
Certainly buggy too, but procedures can actually be created and called....
2002-12-08 19:59:22 +01:00
|
|
|
#endif /* _SP_HEAD_H_ */
|