mirror/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-01-16 20:12:31 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
mariadb/sql/sp.cc

1943 lines
58 KiB
C++
Raw Normal View History

Moved create/find/drop functions to a separate files (sp.cc,sp.h). Fixed backpatching of forward jumps. Implemented LOOP, WHILE, REPEAT (temporarily known as SPREPEAT). Known bug: Expression evaluation still not quite ok (e.g. "x > 0"), which is why IF and CASE is not yet implemented.
2002-12-12 13:14:23 +01:00
/* 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
Many files: Changed header to GPL version 2 only
2006-12-23 20:17:15 +01:00
the Free Software Foundation; version 2 of the License.
Moved create/find/drop functions to a separate files (sp.cc,sp.h). Fixed backpatching of forward jumps. Implemented LOOP, WHILE, REPEAT (temporarily known as SPREPEAT). Known bug: Expression evaluation still not quite ok (e.g. "x > 0"), which is why IF and CASE is not yet implemented.
2002-12-12 13:14:23 +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 */
#include "mysql_priv.h"
#include "sp.h"
#include "sp_head.h"
Code cleanup (and moved sp cache to separate file).
2003-07-03 15:58:37 +02:00
#include "sp_cache.h"
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
#include "sql_trigger.h"
SP cache (WL#730). (Mostly by vva, additions by pem.)
2003-07-01 18:14:24 +02:00
Implementation of WL#2897: Complete definer support in the stored routines. The idea is to add DEFINER-clause in CREATE PROCEDURE and CREATE FUNCTION statements. Almost all support of definer in stored routines had been already done before this patch. NOTE: this patch changes behaviour of dumping stored routines in mysqldump. Before this patch, mysqldump did not dump DEFINER-clause for stored routines and this was documented behaviour. In order to get full information about stored routines, one should have dumped mysql.proc table. This patch changes this behaviour, so that DEFINER-clause is dumped. Since DEFINER-clause is not supported in CREATE PROCEDURE | FUNCTION statements before this patch, the clause is covered by additional version-specific comments.
2006-03-02 13:18:49 +01:00
#include <my_user.h>
Fixed BUG#2564: SHOW CREATE inconsistent W.R.T ANSI_QUOTES. It's not possible to quote the definition according to the current sql_mode setting, so instead we use the setting stored with the SP (that's how it's parsed anyway), and show this setting in the SHOW CREATE output.
2004-06-09 14:19:43 +02:00
static bool
create_string(THD *thd, String *buf,
In order to make ALTER PROCEDURE|FUNCTION work correctly, and in general to make characteristics (and SHOW) work right, we had to separate the old definition blob in the mysql.proc table into separate fields for parameters, return type, and body, and handle the characteristics (like SQL SECURITY) separately... and then reassemble the CREATE string for parsing, of course. This is rather ugly, mostly the parser bit. (Hopefully that will be better with the new parser.)
2003-12-12 14:05:29 +01:00
int sp_type,
Bug#36570: Parse error of CREATE PROCEDURE stmt with comments on \ slave The stored-routine code took the contents of the (lowest) parser and copied it directly to the binlog, which causes problems if there is a special case of interpretation at the parser level -- which there is, in the "/*!VER */" comments. The trailing "*/" caused errors on the slave, naturally. Now, since by that point we have /properly/ created parse-tree (as the rest of the server should do!) for the stored-routine CREATE, we can construct a perfect statement from that information, instead of writing uncertain information from an unknown parser state. Fortunately, there's already a function nearby that does exactly that. --- Update for Bug#36570. Qualify routine names with db name when writing to the binlog ONLY if the source text is qualified.
2008-05-16 01:13:24 +02:00
const char *db, ulong dblen,
Bug#36570: Parse error of CREATE PROCEDURE stmt with comments on \ slave The stored-routine code took the contents of the (lowest) parser and copied it directly to the binlog, which causes problems if there is a special case of interpretation at the parser level -- which there is, in the "/*!VER */" comments. The trailing "*/" caused errors on the slave, naturally. Now, since by that point we have /properly/ created parse-tree (as the rest of the server should do!) for the stored-routine CREATE, we can construct a perfect statement from that information, instead of writing uncertain information from an unknown parser state. Fortunately, there's already a function nearby that does exactly that.
2008-05-15 01:23:54 +02:00
const char *name, ulong namelen,
In order to make ALTER PROCEDURE|FUNCTION work correctly, and in general to make characteristics (and SHOW) work right, we had to separate the old definition blob in the mysql.proc table into separate fields for parameters, return type, and body, and handle the characteristics (like SQL SECURITY) separately... and then reassemble the CREATE string for parsing, of course. This is rather ugly, mostly the parser bit. (Hopefully that will be better with the new parser.)
2003-12-12 14:05:29 +01:00
const char *params, ulong paramslen,
const char *returns, ulong returnslen,
const char *body, ulong bodylen,
Implementation of WL#2897: Complete definer support in the stored routines. The idea is to add DEFINER-clause in CREATE PROCEDURE and CREATE FUNCTION statements. Almost all support of definer in stored routines had been already done before this patch. NOTE: this patch changes behaviour of dumping stored routines in mysqldump. Before this patch, mysqldump did not dump DEFINER-clause for stored routines and this was documented behaviour. In order to get full information about stored routines, one should have dumped mysql.proc table. This patch changes this behaviour, so that DEFINER-clause is dumped. Since DEFINER-clause is not supported in CREATE PROCEDURE | FUNCTION statements before this patch, the clause is covered by additional version-specific comments.
2006-03-02 13:18:49 +01:00
st_sp_chistics *chistics,
const LEX_STRING *definer_user,
const LEX_STRING *definer_host);
Recursion support made for SP (BUG#10100).
2005-11-23 00:11:19 +01:00
static int
db_load_routine(THD *thd, int type, sp_name *name, sp_head **sphp,
ulong sql_mode, const char *params, const char *returns,
const char *body, st_sp_chistics &chistics,
Patch for the following bugs: - BUG#11986: Stored routines and triggers can fail if the code has a non-ascii symbol - BUG#16291: mysqldump corrupts string-constants with non-ascii-chars - BUG#19443: INFORMATION_SCHEMA does not support charsets properly - BUG#21249: Character set of SP-var can be ignored - BUG#25212: Character set of string constant is ignored (stored routines) - BUG#25221: Character set of string constant is ignored (triggers) There were a few general problems that caused these bugs: 1. Character set information of the original (definition) query for views, triggers, stored routines and events was lost. 2. mysqldump output query in client character set, which can be inappropriate to encode definition-query. 3. INFORMATION_SCHEMA used strings with mixed encodings to display object definition; 1. No query-definition-character set. In order to compile query into execution code, some extra data (such as environment variables or the database character set) is used. The problem here was that this context was not preserved. So, on the next load it can differ from the original one, thus the result will be different. The context contains the following data: - client character set; - connection collation (character set and collation); - collation of the owner database; The fix is to store this context and use it each time we parse (compile) and execute the object (stored routine, trigger, ...). 2. Wrong mysqldump-output. The original query can contain several encodings (by means of character set introducers). The problem here was that we tried to convert original query to the mysqldump-client character set. Moreover, we stored queries in different character sets for different objects (views, for one, used UTF8, triggers used original character set). The solution is - to store definition queries in the original character set; - to change SHOW CREATE statement to output definition query in the binary character set (i.e. without any conversion); - introduce SHOW CREATE TRIGGER statement; - to dump special statements to switch the context to the original one before dumping and restore it afterwards. Note, in order to preserve the database collation at the creation time, additional ALTER DATABASE might be used (to temporary switch the database collation back to the original value). In this case, ALTER DATABASE privilege will be required. This is a backward-incompatible change. 3. INFORMATION_SCHEMA showed non-UTF8 strings The fix is to generate UTF8-query during the parsing, store it in the object and show it in the INFORMATION_SCHEMA. Basically, the idea is to create a copy of the original query convert it to UTF8. Character set introducers are removed and all text literals are converted to UTF8. This UTF8 query is intended to provide user-readable output. It must not be used to recreate the object. Specialized SHOW CREATE statements should be used for this. The reason for this limitation is the following: the original query can contain symbols from several character sets (by means of character set introducers). Example: - original query: CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1; - UTF8 query (for INFORMATION_SCHEMA): CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 19:34:54 +02:00
const char *definer, longlong created, longlong modified,
Stored_program_creation_ctx *creation_ctx);
In order to make ALTER PROCEDURE|FUNCTION work correctly, and in general to make characteristics (and SHOW) work right, we had to separate the old definition blob in the mysql.proc table into separate fields for parameters, return type, and body, and handle the characteristics (like SQL SECURITY) separately... and then reassemble the CREATE string for parsing, of course. This is rather ugly, mostly the parser bit. (Hopefully that will be better with the new parser.)
2003-12-12 14:05:29 +01:00
Most of the groundwork for sprint task 729 (implement FUNCTIONs). Expanded the mysql.proc table, reworked the find/create/drop functions completely, added new functions for FUNCTIONs (lotta functions here :), got rid of some unnecessary use of Item_strings while at it. Extended the parser correspondingly, and fiddled around a bit to make SP FUNCTIONs coexist with UDFs. Can now CREATE and DROP FUNCTIONs. Invoking yet to come...
2003-02-21 17:37:05 +01:00
/*
*
* DB storage of Stored PROCEDUREs and FUNCTIONs
*
*/
In order to make ALTER PROCEDURE|FUNCTION work correctly, and in general to make characteristics (and SHOW) work right, we had to separate the old definition blob in the mysql.proc table into separate fields for parameters, return type, and body, and handle the characteristics (like SQL SECURITY) separately... and then reassemble the CREATE string for parsing, of course. This is rather ugly, mostly the parser bit. (Hopefully that will be better with the new parser.)
2003-12-12 14:05:29 +01:00
enum
{
Renamed the "schema" column to "db" in mysql.proc to keep it in style with all the other mysql.* tables.
2003-12-16 19:14:10 +01:00
MYSQL_PROC_FIELD_DB = 0,
In order to make ALTER PROCEDURE|FUNCTION work correctly, and in general to make characteristics (and SHOW) work right, we had to separate the old definition blob in the mysql.proc table into separate fields for parameters, return type, and body, and handle the characteristics (like SQL SECURITY) separately... and then reassemble the CREATE string for parsing, of course. This is rather ugly, mostly the parser bit. (Hopefully that will be better with the new parser.)
2003-12-12 14:05:29 +01:00
MYSQL_PROC_FIELD_NAME,
This finishes the work (someone) started to remove FIELD_ types and use the Enum MYSQL types. The second part to this is to actually deprecate the FIELD defines in mysql_com.h
2006-12-02 02:26:52 +01:00
MYSQL_PROC_MYSQL_TYPE,
In order to make ALTER PROCEDURE|FUNCTION work correctly, and in general to make characteristics (and SHOW) work right, we had to separate the old definition blob in the mysql.proc table into separate fields for parameters, return type, and body, and handle the characteristics (like SQL SECURITY) separately... and then reassemble the CREATE string for parsing, of course. This is rather ugly, mostly the parser bit. (Hopefully that will be better with the new parser.)
2003-12-12 14:05:29 +01:00
MYSQL_PROC_FIELD_SPECIFIC_NAME,
MYSQL_PROC_FIELD_LANGUAGE,
MYSQL_PROC_FIELD_ACCESS,
MYSQL_PROC_FIELD_DETERMINISTIC,
MYSQL_PROC_FIELD_SECURITY_TYPE,
MYSQL_PROC_FIELD_PARAM_LIST,
MYSQL_PROC_FIELD_RETURNS,
MYSQL_PROC_FIELD_BODY,
MYSQL_PROC_FIELD_DEFINER,
MYSQL_PROC_FIELD_CREATED,
MYSQL_PROC_FIELD_MODIFIED,
MYSQL_PROC_FIELD_SQL_MODE,
MYSQL_PROC_FIELD_COMMENT,
Patch for the following bugs: - BUG#11986: Stored routines and triggers can fail if the code has a non-ascii symbol - BUG#16291: mysqldump corrupts string-constants with non-ascii-chars - BUG#19443: INFORMATION_SCHEMA does not support charsets properly - BUG#21249: Character set of SP-var can be ignored - BUG#25212: Character set of string constant is ignored (stored routines) - BUG#25221: Character set of string constant is ignored (triggers) There were a few general problems that caused these bugs: 1. Character set information of the original (definition) query for views, triggers, stored routines and events was lost. 2. mysqldump output query in client character set, which can be inappropriate to encode definition-query. 3. INFORMATION_SCHEMA used strings with mixed encodings to display object definition; 1. No query-definition-character set. In order to compile query into execution code, some extra data (such as environment variables or the database character set) is used. The problem here was that this context was not preserved. So, on the next load it can differ from the original one, thus the result will be different. The context contains the following data: - client character set; - connection collation (character set and collation); - collation of the owner database; The fix is to store this context and use it each time we parse (compile) and execute the object (stored routine, trigger, ...). 2. Wrong mysqldump-output. The original query can contain several encodings (by means of character set introducers). The problem here was that we tried to convert original query to the mysqldump-client character set. Moreover, we stored queries in different character sets for different objects (views, for one, used UTF8, triggers used original character set). The solution is - to store definition queries in the original character set; - to change SHOW CREATE statement to output definition query in the binary character set (i.e. without any conversion); - introduce SHOW CREATE TRIGGER statement; - to dump special statements to switch the context to the original one before dumping and restore it afterwards. Note, in order to preserve the database collation at the creation time, additional ALTER DATABASE might be used (to temporary switch the database collation back to the original value). In this case, ALTER DATABASE privilege will be required. This is a backward-incompatible change. 3. INFORMATION_SCHEMA showed non-UTF8 strings The fix is to generate UTF8-query during the parsing, store it in the object and show it in the INFORMATION_SCHEMA. Basically, the idea is to create a copy of the original query convert it to UTF8. Character set introducers are removed and all text literals are converted to UTF8. This UTF8 query is intended to provide user-readable output. It must not be used to recreate the object. Specialized SHOW CREATE statements should be used for this. The reason for this limitation is the following: the original query can contain symbols from several character sets (by means of character set introducers). Example: - original query: CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1; - UTF8 query (for INFORMATION_SCHEMA): CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 19:34:54 +02:00
MYSQL_PROC_FIELD_CHARACTER_SET_CLIENT,
MYSQL_PROC_FIELD_COLLATION_CONNECTION,
MYSQL_PROC_FIELD_DB_COLLATION,
MYSQL_PROC_FIELD_BODY_UTF8,
In order to make ALTER PROCEDURE|FUNCTION work correctly, and in general to make characteristics (and SHOW) work right, we had to separate the old definition blob in the mysql.proc table into separate fields for parameters, return type, and body, and handle the characteristics (like SQL SECURITY) separately... and then reassemble the CREATE string for parsing, of course. This is rather ugly, mostly the parser bit. (Hopefully that will be better with the new parser.)
2003-12-12 14:05:29 +01:00
MYSQL_PROC_FIELD_COUNT
};
Added more error handling for abnormal cases (like a broken mysql.proc table).
2003-10-30 10:25:45 +01:00
Approximative fixes for BUG#2610,2611,9100 i.e. WL#2146 binlogging/replication of routines (stored procs and functions). Approximative, because it's using our binlogging way (what we call "query"-level) and this is not as good as record-level binlog (5.1) would be. It imposes several limitations to routines, and has caveats (which I'll document, and for which the server will try to issue errors but that is not always possible). Reason I don't propagate caller info to the binlog as planned is that on master and slave users may be different; even with that some caveats would remain.
2005-05-05 14:20:53 +02:00
/* Tells what SP_DEFAULT_ACCESS should be mapped to */
#define SP_DEFAULT_ACCESS_MAPPING SP_CONTAINS_SQL
Patch for the following bugs: - BUG#11986: Stored routines and triggers can fail if the code has a non-ascii symbol - BUG#16291: mysqldump corrupts string-constants with non-ascii-chars - BUG#19443: INFORMATION_SCHEMA does not support charsets properly - BUG#21249: Character set of SP-var can be ignored - BUG#25212: Character set of string constant is ignored (stored routines) - BUG#25221: Character set of string constant is ignored (triggers) There were a few general problems that caused these bugs: 1. Character set information of the original (definition) query for views, triggers, stored routines and events was lost. 2. mysqldump output query in client character set, which can be inappropriate to encode definition-query. 3. INFORMATION_SCHEMA used strings with mixed encodings to display object definition; 1. No query-definition-character set. In order to compile query into execution code, some extra data (such as environment variables or the database character set) is used. The problem here was that this context was not preserved. So, on the next load it can differ from the original one, thus the result will be different. The context contains the following data: - client character set; - connection collation (character set and collation); - collation of the owner database; The fix is to store this context and use it each time we parse (compile) and execute the object (stored routine, trigger, ...). 2. Wrong mysqldump-output. The original query can contain several encodings (by means of character set introducers). The problem here was that we tried to convert original query to the mysqldump-client character set. Moreover, we stored queries in different character sets for different objects (views, for one, used UTF8, triggers used original character set). The solution is - to store definition queries in the original character set; - to change SHOW CREATE statement to output definition query in the binary character set (i.e. without any conversion); - introduce SHOW CREATE TRIGGER statement; - to dump special statements to switch the context to the original one before dumping and restore it afterwards. Note, in order to preserve the database collation at the creation time, additional ALTER DATABASE might be used (to temporary switch the database collation back to the original value). In this case, ALTER DATABASE privilege will be required. This is a backward-incompatible change. 3. INFORMATION_SCHEMA showed non-UTF8 strings The fix is to generate UTF8-query during the parsing, store it in the object and show it in the INFORMATION_SCHEMA. Basically, the idea is to create a copy of the original query convert it to UTF8. Character set introducers are removed and all text literals are converted to UTF8. This UTF8 query is intended to provide user-readable output. It must not be used to recreate the object. Specialized SHOW CREATE statements should be used for this. The reason for this limitation is the following: the original query can contain symbols from several character sets (by means of character set introducers). Example: - original query: CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1; - UTF8 query (for INFORMATION_SCHEMA): CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 19:34:54 +02:00
/*************************************************************************/
/**
Stored_routine_creation_ctx -- creation context of stored routines
(stored procedures and functions).
*/
class Stored_routine_creation_ctx : public Stored_program_creation_ctx,
public Sql_alloc
{
public:
static Stored_routine_creation_ctx *
Fix doxygen warnings.
2007-08-15 15:43:08 +02:00
load_from_db(THD *thd, const sp_name *name, TABLE *proc_tbl);
Patch for the following bugs: - BUG#11986: Stored routines and triggers can fail if the code has a non-ascii symbol - BUG#16291: mysqldump corrupts string-constants with non-ascii-chars - BUG#19443: INFORMATION_SCHEMA does not support charsets properly - BUG#21249: Character set of SP-var can be ignored - BUG#25212: Character set of string constant is ignored (stored routines) - BUG#25221: Character set of string constant is ignored (triggers) There were a few general problems that caused these bugs: 1. Character set information of the original (definition) query for views, triggers, stored routines and events was lost. 2. mysqldump output query in client character set, which can be inappropriate to encode definition-query. 3. INFORMATION_SCHEMA used strings with mixed encodings to display object definition; 1. No query-definition-character set. In order to compile query into execution code, some extra data (such as environment variables or the database character set) is used. The problem here was that this context was not preserved. So, on the next load it can differ from the original one, thus the result will be different. The context contains the following data: - client character set; - connection collation (character set and collation); - collation of the owner database; The fix is to store this context and use it each time we parse (compile) and execute the object (stored routine, trigger, ...). 2. Wrong mysqldump-output. The original query can contain several encodings (by means of character set introducers). The problem here was that we tried to convert original query to the mysqldump-client character set. Moreover, we stored queries in different character sets for different objects (views, for one, used UTF8, triggers used original character set). The solution is - to store definition queries in the original character set; - to change SHOW CREATE statement to output definition query in the binary character set (i.e. without any conversion); - introduce SHOW CREATE TRIGGER statement; - to dump special statements to switch the context to the original one before dumping and restore it afterwards. Note, in order to preserve the database collation at the creation time, additional ALTER DATABASE might be used (to temporary switch the database collation back to the original value). In this case, ALTER DATABASE privilege will be required. This is a backward-incompatible change. 3. INFORMATION_SCHEMA showed non-UTF8 strings The fix is to generate UTF8-query during the parsing, store it in the object and show it in the INFORMATION_SCHEMA. Basically, the idea is to create a copy of the original query convert it to UTF8. Character set introducers are removed and all text literals are converted to UTF8. This UTF8 query is intended to provide user-readable output. It must not be used to recreate the object. Specialized SHOW CREATE statements should be used for this. The reason for this limitation is the following: the original query can contain symbols from several character sets (by means of character set introducers). Example: - original query: CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1; - UTF8 query (for INFORMATION_SCHEMA): CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 19:34:54 +02:00
public:
virtual Stored_program_creation_ctx *clone(MEM_ROOT *mem_root)
{
return new (mem_root) Stored_routine_creation_ctx(m_client_cs,
m_connection_cl,
m_db_cl);
}
protected:
virtual Object_creation_ctx *create_backup_ctx(THD *thd) const
{
Fixed a lot of compiler warnings and errors detected by Forte C++ on Solaris Faster thr_alarm() Added 'Opened_files' status variable to track calls to my_open() Don't give warnings when running mysql_install_db Added option --source-install to mysql_install_db I had to do the following renames() as used polymorphism didn't work with Forte compiler on 64 bit systems index_read() -> index_read_map() index_read_idx() -> index_read_idx_map() index_read_last() -> index_read_last_map()
2007-08-13 15:11:25 +02:00
DBUG_ENTER("Stored_routine_creation_ctx::create_backup_ctx");
DBUG_RETURN(new Stored_routine_creation_ctx(thd));
Patch for the following bugs: - BUG#11986: Stored routines and triggers can fail if the code has a non-ascii symbol - BUG#16291: mysqldump corrupts string-constants with non-ascii-chars - BUG#19443: INFORMATION_SCHEMA does not support charsets properly - BUG#21249: Character set of SP-var can be ignored - BUG#25212: Character set of string constant is ignored (stored routines) - BUG#25221: Character set of string constant is ignored (triggers) There were a few general problems that caused these bugs: 1. Character set information of the original (definition) query for views, triggers, stored routines and events was lost. 2. mysqldump output query in client character set, which can be inappropriate to encode definition-query. 3. INFORMATION_SCHEMA used strings with mixed encodings to display object definition; 1. No query-definition-character set. In order to compile query into execution code, some extra data (such as environment variables or the database character set) is used. The problem here was that this context was not preserved. So, on the next load it can differ from the original one, thus the result will be different. The context contains the following data: - client character set; - connection collation (character set and collation); - collation of the owner database; The fix is to store this context and use it each time we parse (compile) and execute the object (stored routine, trigger, ...). 2. Wrong mysqldump-output. The original query can contain several encodings (by means of character set introducers). The problem here was that we tried to convert original query to the mysqldump-client character set. Moreover, we stored queries in different character sets for different objects (views, for one, used UTF8, triggers used original character set). The solution is - to store definition queries in the original character set; - to change SHOW CREATE statement to output definition query in the binary character set (i.e. without any conversion); - introduce SHOW CREATE TRIGGER statement; - to dump special statements to switch the context to the original one before dumping and restore it afterwards. Note, in order to preserve the database collation at the creation time, additional ALTER DATABASE might be used (to temporary switch the database collation back to the original value). In this case, ALTER DATABASE privilege will be required. This is a backward-incompatible change. 3. INFORMATION_SCHEMA showed non-UTF8 strings The fix is to generate UTF8-query during the parsing, store it in the object and show it in the INFORMATION_SCHEMA. Basically, the idea is to create a copy of the original query convert it to UTF8. Character set introducers are removed and all text literals are converted to UTF8. This UTF8 query is intended to provide user-readable output. It must not be used to recreate the object. Specialized SHOW CREATE statements should be used for this. The reason for this limitation is the following: the original query can contain symbols from several character sets (by means of character set introducers). Example: - original query: CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1; - UTF8 query (for INFORMATION_SCHEMA): CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 19:34:54 +02:00
}
private:
Stored_routine_creation_ctx(THD *thd)
: Stored_program_creation_ctx(thd)
{ }
Stored_routine_creation_ctx(CHARSET_INFO *client_cs,
CHARSET_INFO *connection_cl,
CHARSET_INFO *db_cl)
: Stored_program_creation_ctx(client_cs, connection_cl, db_cl)
{ }
};
/**************************************************************************
Stored_routine_creation_ctx implementation.
**************************************************************************/
bool load_charset(MEM_ROOT *mem_root,
Field *field,
CHARSET_INFO *dflt_cs,
CHARSET_INFO **cs)
{
String cs_name;
if (get_field(mem_root, field, &cs_name))
{
*cs= dflt_cs;
return TRUE;
}
*cs= get_charset_by_csname(cs_name.c_ptr(), MY_CS_PRIMARY, MYF(0));
if (*cs == NULL)
{
*cs= dflt_cs;
return TRUE;
}
return FALSE;
}
/*************************************************************************/
bool load_collation(MEM_ROOT *mem_root,
Field *field,
CHARSET_INFO *dflt_cl,
CHARSET_INFO **cl)
{
String cl_name;
if (get_field(mem_root, field, &cl_name))
{
*cl= dflt_cl;
return TRUE;
}
*cl= get_charset_by_name(cl_name.c_ptr(), MYF(0));
if (*cl == NULL)
{
*cl= dflt_cl;
return TRUE;
}
return FALSE;
}
/*************************************************************************/
Stored_routine_creation_ctx *
Stored_routine_creation_ctx::load_from_db(THD *thd,
const sp_name *name,
TABLE *proc_tbl)
{
/* Load character set/collation attributes. */
CHARSET_INFO *client_cs;
CHARSET_INFO *connection_cl;
CHARSET_INFO *db_cl;
const char *db_name= thd->strmake(name->m_db.str, name->m_db.length);
const char *sr_name= thd->strmake(name->m_name.str, name->m_name.length);
bool invalid_creation_ctx= FALSE;
if (load_charset(thd->mem_root,
proc_tbl->field[MYSQL_PROC_FIELD_CHARACTER_SET_CLIENT],
thd->variables.character_set_client,
&client_cs))
{
sql_print_warning("Stored routine '%s'.'%s': invalid value "
"in column mysql.proc.character_set_client.",
(const char *) db_name,
(const char *) sr_name);
invalid_creation_ctx= TRUE;
}
if (load_collation(thd->mem_root,
proc_tbl->field[MYSQL_PROC_FIELD_COLLATION_CONNECTION],
thd->variables.collation_connection,
&connection_cl))
{
sql_print_warning("Stored routine '%s'.'%s': invalid value "
"in column mysql.proc.collation_connection.",
(const char *) db_name,
(const char *) sr_name);
invalid_creation_ctx= TRUE;
}
if (load_collation(thd->mem_root,
proc_tbl->field[MYSQL_PROC_FIELD_DB_COLLATION],
NULL,
&db_cl))
{
sql_print_warning("Stored routine '%s'.'%s': invalid value "
"in column mysql.proc.db_collation.",
(const char *) db_name,
(const char *) sr_name);
invalid_creation_ctx= TRUE;
}
if (invalid_creation_ctx)
{
push_warning_printf(thd,
MYSQL_ERROR::WARN_LEVEL_WARN,
ER_SR_INVALID_CREATION_CTX,
ER(ER_SR_INVALID_CREATION_CTX),
(const char *) db_name,
(const char *) sr_name);
}
/*
If we failed to retrieve the database collation, load the default one
from the disk.
*/
if (!db_cl)
db_cl= get_default_db_collation(thd, name->m_db.str);
/* Create the context. */
return new Stored_routine_creation_ctx(client_cs, connection_cl, db_cl);
}
/*************************************************************************/
Implementation of Monty's idea: Now we can open mysql.proc table for lookup of stored routines definitions even if we already have some tables open and locked. To avoid deadlocks in this case we have to put certain restrictions on locking of mysql.proc table. This allows to use stored routines safely under LOCK TABLES without explicitly mentioning mysql.proc in the list of locked tables. It also fixes bug #11554 "Server crashes on statement indirectly using non-cached function".
2005-07-13 11:48:13 +02:00
Doxygenized comments.
2007-10-11 20:37:45 +02:00
/**
Implementation of Monty's idea: Now we can open mysql.proc table for lookup of stored routines definitions even if we already have some tables open and locked. To avoid deadlocks in this case we have to put certain restrictions on locking of mysql.proc table. This allows to use stored routines safely under LOCK TABLES without explicitly mentioning mysql.proc in the list of locked tables. It also fixes bug #11554 "Server crashes on statement indirectly using non-cached function".
2005-07-13 11:48:13 +02:00
Open the mysql.proc table for read.
Doxygenized comments.
2007-10-11 20:37:45 +02:00
@param thd Thread context
@param backup Pointer to Open_tables_state instance where information about
currently open tables will be saved, and from which will be
restored when we will end work with mysql.proc.
Implementation of Monty's idea: Now we can open mysql.proc table for lookup of stored routines definitions even if we already have some tables open and locked. To avoid deadlocks in this case we have to put certain restrictions on locking of mysql.proc table. This allows to use stored routines safely under LOCK TABLES without explicitly mentioning mysql.proc in the list of locked tables. It also fixes bug #11554 "Server crashes on statement indirectly using non-cached function".
2005-07-13 11:48:13 +02:00
Doxygenized comments.
2007-10-11 20:37:45 +02:00
@retval
Implementation of Monty's idea: Now we can open mysql.proc table for lookup of stored routines definitions even if we already have some tables open and locked. To avoid deadlocks in this case we have to put certain restrictions on locking of mysql.proc table. This allows to use stored routines safely under LOCK TABLES without explicitly mentioning mysql.proc in the list of locked tables. It also fixes bug #11554 "Server crashes on statement indirectly using non-cached function".
2005-07-13 11:48:13 +02:00
0 Error
Doxygenized comments.
2007-10-11 20:37:45 +02:00
@retval
\# Pointer to TABLE object of mysql.proc
Implementation of Monty's idea: Now we can open mysql.proc table for lookup of stored routines definitions even if we already have some tables open and locked. To avoid deadlocks in this case we have to put certain restrictions on locking of mysql.proc table. This allows to use stored routines safely under LOCK TABLES without explicitly mentioning mysql.proc in the list of locked tables. It also fixes bug #11554 "Server crashes on statement indirectly using non-cached function".
2005-07-13 11:48:13 +02:00
*/
Fix for bug #10055 "Using stored function with information_schema causes empty result set". To enable full access to contents of I_S tables from stored functions or statements that use them, we manipulate with thread's open tables state and ensure that we won't cause deadlock when we open tables by ignoring flushes and name-locks. Building of contents of I_S.TABLES no longer requires locking of tables since we use use handler::info() method with HA_STATUS_AUTO flag instead of handler::update_auto_increment() for obtaining information about auto-increment values. But this also means that handlers have to implement support for HA_STATUS_AUTO flag (particularly InnoDB needs it).
2005-08-08 15:46:06 +02:00
TABLE *open_proc_table_for_read(THD *thd, Open_tables_state *backup)
Implementation of Monty's idea: Now we can open mysql.proc table for lookup of stored routines definitions even if we already have some tables open and locked. To avoid deadlocks in this case we have to put certain restrictions on locking of mysql.proc table. This allows to use stored routines safely under LOCK TABLES without explicitly mentioning mysql.proc in the list of locked tables. It also fixes bug #11554 "Server crashes on statement indirectly using non-cached function".
2005-07-13 11:48:13 +02:00
{
BUG#9953: CONVERT_TZ requires mysql.time_zone_name to be locked The problem was that some facilities (like CONVERT_TZ() function or server HELP statement) may require implicit access to some tables in 'mysql' database. This access was done by ordinary means of adding such tables to the list of tables the query is going to open. However, if we issued LOCK TABLES before that, we would get "table was not locked" error trying to open such implicit tables. The solution is to treat certain tables as MySQL system tables, like we already do for mysql.proc. Such tables may be opened for reading at any moment regardless of any locks in effect. The cost of this is that system table may be locked for writing only together with other system tables, it is disallowed to lock system tables for writing and have any other lock on any other table. After this patch the following tables are treated as MySQL system tables: mysql.help_category mysql.help_keyword mysql.help_relation mysql.help_topic mysql.proc (it already was) mysql.time_zone mysql.time_zone_leap_second mysql.time_zone_name mysql.time_zone_transition mysql.time_zone_transition_type These tables are now opened with open_system_tables_for_read() and closed with close_system_tables(), or one table may be opened with open_system_table_for_update() and closed with close_thread_tables() (the latter is used for mysql.proc table, which is updated as part of normal MySQL server operation). These functions may be used when some tables were opened and locked already. NOTE: online update of time zone tables is not possible during replication, because there's no time zone cache flush neither on LOCK TABLES, nor on FLUSH TABLES, so the master may serve stale time zone data from cache, while on slave updated data will be loaded from the time zone tables.
2007-03-09 11:12:31 +01:00
DBUG_ENTER("open_proc_table_for_read");
Made FUNCTIONs work in insert and select queries, as well as nested function invocations. Had to add a cahing mechanism which is in parts an ugly kludge, but it will be reworked once the real SP caching is implemented.
2003-03-02 19:17:41 +01:00
BUG#9953: CONVERT_TZ requires mysql.time_zone_name to be locked The problem was that some facilities (like CONVERT_TZ() function or server HELP statement) may require implicit access to some tables in 'mysql' database. This access was done by ordinary means of adding such tables to the list of tables the query is going to open. However, if we issued LOCK TABLES before that, we would get "table was not locked" error trying to open such implicit tables. The solution is to treat certain tables as MySQL system tables, like we already do for mysql.proc. Such tables may be opened for reading at any moment regardless of any locks in effect. The cost of this is that system table may be locked for writing only together with other system tables, it is disallowed to lock system tables for writing and have any other lock on any other table. After this patch the following tables are treated as MySQL system tables: mysql.help_category mysql.help_keyword mysql.help_relation mysql.help_topic mysql.proc (it already was) mysql.time_zone mysql.time_zone_leap_second mysql.time_zone_name mysql.time_zone_transition mysql.time_zone_transition_type These tables are now opened with open_system_tables_for_read() and closed with close_system_tables(), or one table may be opened with open_system_table_for_update() and closed with close_thread_tables() (the latter is used for mysql.proc table, which is updated as part of normal MySQL server operation). These functions may be used when some tables were opened and locked already. NOTE: online update of time zone tables is not possible during replication, because there's no time zone cache flush neither on LOCK TABLES, nor on FLUSH TABLES, so the master may serve stale time zone data from cache, while on slave updated data will be loaded from the time zone tables.
2007-03-09 11:12:31 +01:00
TABLE_LIST table;
bzero((char*) &table, sizeof(table));
table.db= (char*) "mysql";
table.table_name= table.alias= (char*)"proc";
table.lock_type= TL_READ;
Implementation of Monty's idea: Now we can open mysql.proc table for lookup of stored routines definitions even if we already have some tables open and locked. To avoid deadlocks in this case we have to put certain restrictions on locking of mysql.proc table. This allows to use stored routines safely under LOCK TABLES without explicitly mentioning mysql.proc in the list of locked tables. It also fixes bug #11554 "Server crashes on statement indirectly using non-cached function".
2005-07-13 11:48:13 +02:00
BUG#9953: CONVERT_TZ requires mysql.time_zone_name to be locked The problem was that some facilities (like CONVERT_TZ() function or server HELP statement) may require implicit access to some tables in 'mysql' database. This access was done by ordinary means of adding such tables to the list of tables the query is going to open. However, if we issued LOCK TABLES before that, we would get "table was not locked" error trying to open such implicit tables. The solution is to treat certain tables as MySQL system tables, like we already do for mysql.proc. Such tables may be opened for reading at any moment regardless of any locks in effect. The cost of this is that system table may be locked for writing only together with other system tables, it is disallowed to lock system tables for writing and have any other lock on any other table. After this patch the following tables are treated as MySQL system tables: mysql.help_category mysql.help_keyword mysql.help_relation mysql.help_topic mysql.proc (it already was) mysql.time_zone mysql.time_zone_leap_second mysql.time_zone_name mysql.time_zone_transition mysql.time_zone_transition_type These tables are now opened with open_system_tables_for_read() and closed with close_system_tables(), or one table may be opened with open_system_table_for_update() and closed with close_thread_tables() (the latter is used for mysql.proc table, which is updated as part of normal MySQL server operation). These functions may be used when some tables were opened and locked already. NOTE: online update of time zone tables is not possible during replication, because there's no time zone cache flush neither on LOCK TABLES, nor on FLUSH TABLES, so the master may serve stale time zone data from cache, while on slave updated data will be loaded from the time zone tables.
2007-03-09 11:12:31 +01:00
if (!open_system_tables_for_read(thd, &table, backup))
DBUG_RETURN(table.table);
else
Implementation of Monty's idea: Now we can open mysql.proc table for lookup of stored routines definitions even if we already have some tables open and locked. To avoid deadlocks in this case we have to put certain restrictions on locking of mysql.proc table. This allows to use stored routines safely under LOCK TABLES without explicitly mentioning mysql.proc in the list of locked tables. It also fixes bug #11554 "Server crashes on statement indirectly using non-cached function".
2005-07-13 11:48:13 +02:00
DBUG_RETURN(0);
}
Doxygenized comments.
2007-10-11 20:37:45 +02:00
/**
Implementation of Monty's idea: Now we can open mysql.proc table for lookup of stored routines definitions even if we already have some tables open and locked. To avoid deadlocks in this case we have to put certain restrictions on locking of mysql.proc table. This allows to use stored routines safely under LOCK TABLES without explicitly mentioning mysql.proc in the list of locked tables. It also fixes bug #11554 "Server crashes on statement indirectly using non-cached function".
2005-07-13 11:48:13 +02:00
Open the mysql.proc table for update.
Doxygenized comments.
2007-10-11 20:37:45 +02:00
@param thd Thread context
Implementation of Monty's idea: Now we can open mysql.proc table for lookup of stored routines definitions even if we already have some tables open and locked. To avoid deadlocks in this case we have to put certain restrictions on locking of mysql.proc table. This allows to use stored routines safely under LOCK TABLES without explicitly mentioning mysql.proc in the list of locked tables. It also fixes bug #11554 "Server crashes on statement indirectly using non-cached function".
2005-07-13 11:48:13 +02:00
Doxygenized comments.
2007-10-11 20:37:45 +02:00
@note
Implementation of Monty's idea: Now we can open mysql.proc table for lookup of stored routines definitions even if we already have some tables open and locked. To avoid deadlocks in this case we have to put certain restrictions on locking of mysql.proc table. This allows to use stored routines safely under LOCK TABLES without explicitly mentioning mysql.proc in the list of locked tables. It also fixes bug #11554 "Server crashes on statement indirectly using non-cached function".
2005-07-13 11:48:13 +02:00
Table opened with this call should closed using close_thread_tables().
Doxygenized comments.
2007-10-11 20:37:45 +02:00
@retval
Implementation of Monty's idea: Now we can open mysql.proc table for lookup of stored routines definitions even if we already have some tables open and locked. To avoid deadlocks in this case we have to put certain restrictions on locking of mysql.proc table. This allows to use stored routines safely under LOCK TABLES without explicitly mentioning mysql.proc in the list of locked tables. It also fixes bug #11554 "Server crashes on statement indirectly using non-cached function".
2005-07-13 11:48:13 +02:00
0 Error
Doxygenized comments.
2007-10-11 20:37:45 +02:00
@retval
\# Pointer to TABLE object of mysql.proc
Implementation of Monty's idea: Now we can open mysql.proc table for lookup of stored routines definitions even if we already have some tables open and locked. To avoid deadlocks in this case we have to put certain restrictions on locking of mysql.proc table. This allows to use stored routines safely under LOCK TABLES without explicitly mentioning mysql.proc in the list of locked tables. It also fixes bug #11554 "Server crashes on statement indirectly using non-cached function".
2005-07-13 11:48:13 +02:00
*/
static TABLE *open_proc_table_for_update(THD *thd)
{
BUG#9953: CONVERT_TZ requires mysql.time_zone_name to be locked The problem was that some facilities (like CONVERT_TZ() function or server HELP statement) may require implicit access to some tables in 'mysql' database. This access was done by ordinary means of adding such tables to the list of tables the query is going to open. However, if we issued LOCK TABLES before that, we would get "table was not locked" error trying to open such implicit tables. The solution is to treat certain tables as MySQL system tables, like we already do for mysql.proc. Such tables may be opened for reading at any moment regardless of any locks in effect. The cost of this is that system table may be locked for writing only together with other system tables, it is disallowed to lock system tables for writing and have any other lock on any other table. After this patch the following tables are treated as MySQL system tables: mysql.help_category mysql.help_keyword mysql.help_relation mysql.help_topic mysql.proc (it already was) mysql.time_zone mysql.time_zone_leap_second mysql.time_zone_name mysql.time_zone_transition mysql.time_zone_transition_type These tables are now opened with open_system_tables_for_read() and closed with close_system_tables(), or one table may be opened with open_system_table_for_update() and closed with close_thread_tables() (the latter is used for mysql.proc table, which is updated as part of normal MySQL server operation). These functions may be used when some tables were opened and locked already. NOTE: online update of time zone tables is not possible during replication, because there's no time zone cache flush neither on LOCK TABLES, nor on FLUSH TABLES, so the master may serve stale time zone data from cache, while on slave updated data will be loaded from the time zone tables.
2007-03-09 11:12:31 +01:00
DBUG_ENTER("open_proc_table_for_update");
Implementation of Monty's idea: Now we can open mysql.proc table for lookup of stored routines definitions even if we already have some tables open and locked. To avoid deadlocks in this case we have to put certain restrictions on locking of mysql.proc table. This allows to use stored routines safely under LOCK TABLES without explicitly mentioning mysql.proc in the list of locked tables. It also fixes bug #11554 "Server crashes on statement indirectly using non-cached function".
2005-07-13 11:48:13 +02:00
BUG#9953: CONVERT_TZ requires mysql.time_zone_name to be locked The problem was that some facilities (like CONVERT_TZ() function or server HELP statement) may require implicit access to some tables in 'mysql' database. This access was done by ordinary means of adding such tables to the list of tables the query is going to open. However, if we issued LOCK TABLES before that, we would get "table was not locked" error trying to open such implicit tables. The solution is to treat certain tables as MySQL system tables, like we already do for mysql.proc. Such tables may be opened for reading at any moment regardless of any locks in effect. The cost of this is that system table may be locked for writing only together with other system tables, it is disallowed to lock system tables for writing and have any other lock on any other table. After this patch the following tables are treated as MySQL system tables: mysql.help_category mysql.help_keyword mysql.help_relation mysql.help_topic mysql.proc (it already was) mysql.time_zone mysql.time_zone_leap_second mysql.time_zone_name mysql.time_zone_transition mysql.time_zone_transition_type These tables are now opened with open_system_tables_for_read() and closed with close_system_tables(), or one table may be opened with open_system_table_for_update() and closed with close_thread_tables() (the latter is used for mysql.proc table, which is updated as part of normal MySQL server operation). These functions may be used when some tables were opened and locked already. NOTE: online update of time zone tables is not possible during replication, because there's no time zone cache flush neither on LOCK TABLES, nor on FLUSH TABLES, so the master may serve stale time zone data from cache, while on slave updated data will be loaded from the time zone tables.
2007-03-09 11:12:31 +01:00
TABLE_LIST table;
bzero((char*) &table, sizeof(table));
table.db= (char*) "mysql";
table.table_name= table.alias= (char*)"proc";
table.lock_type= TL_WRITE;
Implementation of Monty's idea: Now we can open mysql.proc table for lookup of stored routines definitions even if we already have some tables open and locked. To avoid deadlocks in this case we have to put certain restrictions on locking of mysql.proc table. This allows to use stored routines safely under LOCK TABLES without explicitly mentioning mysql.proc in the list of locked tables. It also fixes bug #11554 "Server crashes on statement indirectly using non-cached function".
2005-07-13 11:48:13 +02:00
BUG#9953: CONVERT_TZ requires mysql.time_zone_name to be locked The problem was that some facilities (like CONVERT_TZ() function or server HELP statement) may require implicit access to some tables in 'mysql' database. This access was done by ordinary means of adding such tables to the list of tables the query is going to open. However, if we issued LOCK TABLES before that, we would get "table was not locked" error trying to open such implicit tables. The solution is to treat certain tables as MySQL system tables, like we already do for mysql.proc. Such tables may be opened for reading at any moment regardless of any locks in effect. The cost of this is that system table may be locked for writing only together with other system tables, it is disallowed to lock system tables for writing and have any other lock on any other table. After this patch the following tables are treated as MySQL system tables: mysql.help_category mysql.help_keyword mysql.help_relation mysql.help_topic mysql.proc (it already was) mysql.time_zone mysql.time_zone_leap_second mysql.time_zone_name mysql.time_zone_transition mysql.time_zone_transition_type These tables are now opened with open_system_tables_for_read() and closed with close_system_tables(), or one table may be opened with open_system_table_for_update() and closed with close_thread_tables() (the latter is used for mysql.proc table, which is updated as part of normal MySQL server operation). These functions may be used when some tables were opened and locked already. NOTE: online update of time zone tables is not possible during replication, because there's no time zone cache flush neither on LOCK TABLES, nor on FLUSH TABLES, so the master may serve stale time zone data from cache, while on slave updated data will be loaded from the time zone tables.
2007-03-09 11:12:31 +01:00
DBUG_RETURN(open_system_table_for_update(thd, &table));
Implementation of Monty's idea: Now we can open mysql.proc table for lookup of stored routines definitions even if we already have some tables open and locked. To avoid deadlocks in this case we have to put certain restrictions on locking of mysql.proc table. This allows to use stored routines safely under LOCK TABLES without explicitly mentioning mysql.proc in the list of locked tables. It also fixes bug #11554 "Server crashes on statement indirectly using non-cached function".
2005-07-13 11:48:13 +02:00
}
Doxygenized comments.
2007-10-11 20:37:45 +02:00
/**
Implementation of Monty's idea: Now we can open mysql.proc table for lookup of stored routines definitions even if we already have some tables open and locked. To avoid deadlocks in this case we have to put certain restrictions on locking of mysql.proc table. This allows to use stored routines safely under LOCK TABLES without explicitly mentioning mysql.proc in the list of locked tables. It also fixes bug #11554 "Server crashes on statement indirectly using non-cached function".
2005-07-13 11:48:13 +02:00
Find row in open mysql.proc table representing stored routine.
Doxygenized comments.
2007-10-11 20:37:45 +02:00
@param thd Thread context
@param type Type of routine to find (function or procedure)
@param name Name of routine
@param table TABLE object for open mysql.proc table.
Implementation of Monty's idea: Now we can open mysql.proc table for lookup of stored routines definitions even if we already have some tables open and locked. To avoid deadlocks in this case we have to put certain restrictions on locking of mysql.proc table. This allows to use stored routines safely under LOCK TABLES without explicitly mentioning mysql.proc in the list of locked tables. It also fixes bug #11554 "Server crashes on statement indirectly using non-cached function".
2005-07-13 11:48:13 +02:00
Doxygenized comments.
2007-10-11 20:37:45 +02:00
@retval
SP_OK Routine found
@retval
SP_KEY_NOT_FOUND No routine with given name
Implementation of Monty's idea: Now we can open mysql.proc table for lookup of stored routines definitions even if we already have some tables open and locked. To avoid deadlocks in this case we have to put certain restrictions on locking of mysql.proc table. This allows to use stored routines safely under LOCK TABLES without explicitly mentioning mysql.proc in the list of locked tables. It also fixes bug #11554 "Server crashes on statement indirectly using non-cached function".
2005-07-13 11:48:13 +02:00
*/
static int
db_find_routine_aux(THD *thd, int type, sp_name *name, TABLE *table)
{
WL#3817: Simplify string / memory area types and make things more consistent (first part) The following type conversions was done: - Changed byte to uchar - Changed gptr to uchar* - Change my_string to char * - Change my_size_t to size_t - Change size_s to size_t Removed declaration of byte, gptr, my_string, my_size_t and size_s. Following function parameter changes was done: - All string functions in mysys/strings was changed to use size_t instead of uint for string lengths. - All read()/write() functions changed to use size_t (including vio). - All protocoll functions changed to use size_t instead of uint - Functions that used a pointer to a string length was changed to use size_t* - Changed malloc(), free() and related functions from using gptr to use void * as this requires fewer casts in the code and is more in line with how the standard functions work. - Added extra length argument to dirname_part() to return the length of the created string. - Changed (at least) following functions to take uchar* as argument: - db_dump() - my_net_write() - net_write_command() - net_store_data() - DBUG_DUMP() - decimal2bin() & bin2decimal() - Changed my_compress() and my_uncompress() to use size_t. Changed one argument to my_uncompress() from a pointer to a value as we only return one value (makes function easier to use). - Changed type of 'pack_data' argument to packfrm() to avoid casts. - Changed in readfrm() and writefrom(), ha_discover and handler::discover() the type for argument 'frmdata' to uchar** to avoid casts. - Changed most Field functions to use uchar* instead of char* (reduced a lot of casts). - Changed field->val_xxx(xxx, new_ptr) to take const pointers. Other changes: - Removed a lot of not needed casts - Added a few new cast required by other changes - Added some cast to my_multi_malloc() arguments for safety (as string lengths needs to be uint, not size_t). - Fixed all calls to hash-get-key functions to use size_t*. (Needed to be done explicitely as this conflict was often hided by casting the function to hash_get_key). - Changed some buffers to memory regions to uchar* to avoid casts. - Changed some string lengths from uint to size_t. - Changed field->ptr to be uchar* instead of char*. This allowed us to get rid of a lot of casts. - Some changes from true -> TRUE, false -> FALSE, unsigned char -> uchar - Include zlib.h in some files as we needed declaration of crc32() - Changed MY_FILE_ERROR to be (size_t) -1. - Changed many variables to hold the result of my_read() / my_write() to be size_t. This was needed to properly detect errors (which are returned as (size_t) -1). - Removed some very old VMS code - Changed packfrm()/unpackfrm() to not be depending on uint size (portability fix) - Removed windows specific code to restore cursor position as this causes slowdown on windows and we should not mix read() and pread() calls anyway as this is not thread safe. Updated function comment to reflect this. Changed function that depended on original behavior of my_pwrite() to itself restore the cursor position (one such case). - Added some missing checking of return value of malloc(). - Changed definition of MOD_PAD_CHAR_TO_FULL_LENGTH to avoid 'long' overflow. - Changed type of table_def::m_size from my_size_t to ulong to reflect that m_size is the number of elements in the array, not a string/memory length. - Moved THD::max_row_length() to table.cc (as it's not depending on THD). Inlined max_row_length_blob() into this function. - More function comments - Fixed some compiler warnings when compiled without partitions. - Removed setting of LEX_STRING() arguments in declaration (portability fix). - Some trivial indentation/variable name changes. - Some trivial code simplifications: - Replaced some calls to alloc_root + memcpy to use strmake_root()/strdup_root(). - Changed some calls from memdup() to strmake() (Safety fix) - Simpler loops in client-simple.c
2007-05-10 11:59:39 +02:00
uchar key[MAX_KEY_LENGTH]; // db, name, optional key length type
Implementation of Monty's idea: Now we can open mysql.proc table for lookup of stored routines definitions even if we already have some tables open and locked. To avoid deadlocks in this case we have to put certain restrictions on locking of mysql.proc table. This allows to use stored routines safely under LOCK TABLES without explicitly mentioning mysql.proc in the list of locked tables. It also fixes bug #11554 "Server crashes on statement indirectly using non-cached function".
2005-07-13 11:48:13 +02:00
DBUG_ENTER("db_find_routine_aux");
WL#3817: Simplify string / memory area types and make things more consistent (first part) The following type conversions was done: - Changed byte to uchar - Changed gptr to uchar* - Change my_string to char * - Change my_size_t to size_t - Change size_s to size_t Removed declaration of byte, gptr, my_string, my_size_t and size_s. Following function parameter changes was done: - All string functions in mysys/strings was changed to use size_t instead of uint for string lengths. - All read()/write() functions changed to use size_t (including vio). - All protocoll functions changed to use size_t instead of uint - Functions that used a pointer to a string length was changed to use size_t* - Changed malloc(), free() and related functions from using gptr to use void * as this requires fewer casts in the code and is more in line with how the standard functions work. - Added extra length argument to dirname_part() to return the length of the created string. - Changed (at least) following functions to take uchar* as argument: - db_dump() - my_net_write() - net_write_command() - net_store_data() - DBUG_DUMP() - decimal2bin() & bin2decimal() - Changed my_compress() and my_uncompress() to use size_t. Changed one argument to my_uncompress() from a pointer to a value as we only return one value (makes function easier to use). - Changed type of 'pack_data' argument to packfrm() to avoid casts. - Changed in readfrm() and writefrom(), ha_discover and handler::discover() the type for argument 'frmdata' to uchar** to avoid casts. - Changed most Field functions to use uchar* instead of char* (reduced a lot of casts). - Changed field->val_xxx(xxx, new_ptr) to take const pointers. Other changes: - Removed a lot of not needed casts - Added a few new cast required by other changes - Added some cast to my_multi_malloc() arguments for safety (as string lengths needs to be uint, not size_t). - Fixed all calls to hash-get-key functions to use size_t*. (Needed to be done explicitely as this conflict was often hided by casting the function to hash_get_key). - Changed some buffers to memory regions to uchar* to avoid casts. - Changed some string lengths from uint to size_t. - Changed field->ptr to be uchar* instead of char*. This allowed us to get rid of a lot of casts. - Some changes from true -> TRUE, false -> FALSE, unsigned char -> uchar - Include zlib.h in some files as we needed declaration of crc32() - Changed MY_FILE_ERROR to be (size_t) -1. - Changed many variables to hold the result of my_read() / my_write() to be size_t. This was needed to properly detect errors (which are returned as (size_t) -1). - Removed some very old VMS code - Changed packfrm()/unpackfrm() to not be depending on uint size (portability fix) - Removed windows specific code to restore cursor position as this causes slowdown on windows and we should not mix read() and pread() calls anyway as this is not thread safe. Updated function comment to reflect this. Changed function that depended on original behavior of my_pwrite() to itself restore the cursor position (one such case). - Added some missing checking of return value of malloc(). - Changed definition of MOD_PAD_CHAR_TO_FULL_LENGTH to avoid 'long' overflow. - Changed type of table_def::m_size from my_size_t to ulong to reflect that m_size is the number of elements in the array, not a string/memory length. - Moved THD::max_row_length() to table.cc (as it's not depending on THD). Inlined max_row_length_blob() into this function. - More function comments - Fixed some compiler warnings when compiled without partitions. - Removed setting of LEX_STRING() arguments in declaration (portability fix). - Some trivial indentation/variable name changes. - Some trivial code simplifications: - Replaced some calls to alloc_root + memcpy to use strmake_root()/strdup_root(). - Changed some calls from memdup() to strmake() (Safety fix) - Simpler loops in client-simple.c
2007-05-10 11:59:39 +02:00
DBUG_PRINT("enter", ("type: %d name: %.*s",
type, (int) name->m_name.length, name->m_name.str));
Moved create/find/drop functions to a separate files (sp.cc,sp.h). Fixed backpatching of forward jumps. Implemented LOOP, WHILE, REPEAT (temporarily known as SPREPEAT). Known bug: Expression evaluation still not quite ok (e.g. "x > 0"), which is why IF and CASE is not yet implemented.
2002-12-12 13:14:23 +01:00
Don't use -lsupc++ with gcc 3.3 and below as this gives linking problems when linking staticly Fix that mysql.proc works with new VARCHAR fields Give warnings for wrong zero dates
2005-04-04 15:43:25 +02:00
/*
Create key to find row. We have to use field->store() to be able to
handle VARCHAR and CHAR fields.
Assumption here is that the three first fields in the table are
'db', 'name' and 'type' and the first key is the primary key over the
same fields.
*/
Fixed BUG#9529: Stored Procedures: No Warning on truncation of procedure name during creation. Although it returns an error, consistent with the behaviour for other objects. (Unclear why we would allow the creation of SPs with truncated names.)
2005-05-31 18:36:32 +02:00
if (name->m_name.length > table->field[1]->field_length)
DBUG_RETURN(SP_KEY_NOT_FOUND);
Don't use -lsupc++ with gcc 3.3 and below as this gives linking problems when linking staticly Fix that mysql.proc works with new VARCHAR fields Give warnings for wrong zero dates
2005-04-04 15:43:25 +02:00
table->field[0]->store(name->m_db.str, name->m_db.length, &my_charset_bin);
table->field[1]->store(name->m_name.str, name->m_name.length,
&my_charset_bin);
Added option --valgrind-mysqltest to mysql-test-run Added flag to Field::store(longlong) to specify if value is unsigned. This fixes bug #12750: Incorrect storage of 9999999999999999999 in DECIMAL(19, 0) Fixed warning from valgrind in CREATE ... SELECT Fixed double free of mysql.options if reconnect failed
2005-09-14 00:41:44 +02:00
table->field[2]->store((longlong) type, TRUE);
Don't use -lsupc++ with gcc 3.3 and below as this gives linking problems when linking staticly Fix that mysql.proc works with new VARCHAR fields Give warnings for wrong zero dates
2005-04-04 15:43:25 +02:00
key_copy(key, table->record[0], table->key_info,
table->key_info->key_length);
Fixed a lot of compiler warnings and errors detected by Forte C++ on Solaris Faster thr_alarm() Added 'Opened_files' status variable to track calls to my_open() Don't give warnings when running mysql_install_db Added option --source-install to mysql_install_db I had to do the following renames() as used polymorphism didn't work with Forte compiler on 64 bit systems index_read() -> index_read_map() index_read_idx() -> index_read_idx_map() index_read_last() -> index_read_last_map()
2007-08-13 15:11:25 +02:00
if (table->file->index_read_idx_map(table->record[0], 0, key, HA_WHOLE_KEY,
HA_READ_KEY_EXACT))
Most of the groundwork for sprint task 729 (implement FUNCTIONs). Expanded the mysql.proc table, reworked the find/create/drop functions completely, added new functions for FUNCTIONs (lotta functions here :), got rid of some unnecessary use of Item_strings while at it. Extended the parser correspondingly, and fiddled around a bit to make SP FUNCTIONs coexist with UDFs. Can now CREATE and DROP FUNCTIONs. Invoking yet to come...
2003-02-21 17:37:05 +01:00
DBUG_RETURN(SP_KEY_NOT_FOUND);
Moved create/find/drop functions to a separate files (sp.cc,sp.h). Fixed backpatching of forward jumps. Implemented LOOP, WHILE, REPEAT (temporarily known as SPREPEAT). Known bug: Expression evaluation still not quite ok (e.g. "x > 0"), which is why IF and CASE is not yet implemented.
2002-12-12 13:14:23 +01:00
Most of the groundwork for sprint task 729 (implement FUNCTIONs). Expanded the mysql.proc table, reworked the find/create/drop functions completely, added new functions for FUNCTIONs (lotta functions here :), got rid of some unnecessary use of Item_strings while at it. Extended the parser correspondingly, and fiddled around a bit to make SP FUNCTIONs coexist with UDFs. Can now CREATE and DROP FUNCTIONs. Invoking yet to come...
2003-02-21 17:37:05 +01:00
DBUG_RETURN(SP_OK);
}
Fixed memory leaks in SP Some code cleanup
2003-12-21 11:48:03 +01:00
Doxygenized comments.
2007-10-11 20:37:45 +02:00
/**
Implementation of Monty's idea: Now we can open mysql.proc table for lookup of stored routines definitions even if we already have some tables open and locked. To avoid deadlocks in this case we have to put certain restrictions on locking of mysql.proc table. This allows to use stored routines safely under LOCK TABLES without explicitly mentioning mysql.proc in the list of locked tables. It also fixes bug #11554 "Server crashes on statement indirectly using non-cached function".
2005-07-13 11:48:13 +02:00
Find routine definition in mysql.proc table and create corresponding
sp_head object for it.
Doxygenized comments.
2007-10-11 20:37:45 +02:00
@param thd Thread context
@param type Type of routine (TYPE_ENUM_PROCEDURE/...)
@param name Name of routine
@param sphp Out parameter in which pointer to created sp_head
object is returned (0 in case of error).
Implementation of Monty's idea: Now we can open mysql.proc table for lookup of stored routines definitions even if we already have some tables open and locked. To avoid deadlocks in this case we have to put certain restrictions on locking of mysql.proc table. This allows to use stored routines safely under LOCK TABLES without explicitly mentioning mysql.proc in the list of locked tables. It also fixes bug #11554 "Server crashes on statement indirectly using non-cached function".
2005-07-13 11:48:13 +02:00
Doxygenized comments.
2007-10-11 20:37:45 +02:00
@note
Implementation of Monty's idea: Now we can open mysql.proc table for lookup of stored routines definitions even if we already have some tables open and locked. To avoid deadlocks in this case we have to put certain restrictions on locking of mysql.proc table. This allows to use stored routines safely under LOCK TABLES without explicitly mentioning mysql.proc in the list of locked tables. It also fixes bug #11554 "Server crashes on statement indirectly using non-cached function".
2005-07-13 11:48:13 +02:00
This function may damage current LEX during execution, so it is good
idea to create temporary LEX and make it active before calling it.
Doxygenized comments.
2007-10-11 20:37:45 +02:00
@retval
0 Success
@retval
non-0 Error (may be one of special codes like SP_KEY_NOT_FOUND)
Implementation of Monty's idea: Now we can open mysql.proc table for lookup of stored routines definitions even if we already have some tables open and locked. To avoid deadlocks in this case we have to put certain restrictions on locking of mysql.proc table. This allows to use stored routines safely under LOCK TABLES without explicitly mentioning mysql.proc in the list of locked tables. It also fixes bug #11554 "Server crashes on statement indirectly using non-cached function".
2005-07-13 11:48:13 +02:00
*/
Most of the groundwork for sprint task 729 (implement FUNCTIONs). Expanded the mysql.proc table, reworked the find/create/drop functions completely, added new functions for FUNCTIONs (lotta functions here :), got rid of some unnecessary use of Item_strings while at it. Extended the parser correspondingly, and fiddled around a bit to make SP FUNCTIONs coexist with UDFs. Can now CREATE and DROP FUNCTIONs. Invoking yet to come...
2003-02-21 17:37:05 +01:00
static int
WL#1366: Use the schema (db) associated with an SP. Phase 1: Introduced sp_name class, for qualified name support.
2004-02-17 17:36:53 +01:00
db_find_routine(THD *thd, int type, sp_name *name, sp_head **sphp)
Most of the groundwork for sprint task 729 (implement FUNCTIONs). Expanded the mysql.proc table, reworked the find/create/drop functions completely, added new functions for FUNCTIONs (lotta functions here :), got rid of some unnecessary use of Item_strings while at it. Extended the parser correspondingly, and fiddled around a bit to make SP FUNCTIONs coexist with UDFs. Can now CREATE and DROP FUNCTIONs. Invoking yet to come...
2003-02-21 17:37:05 +01:00
{
TABLE *table;
In order to make ALTER PROCEDURE|FUNCTION work correctly, and in general to make characteristics (and SHOW) work right, we had to separate the old definition blob in the mysql.proc table into separate fields for parameters, return type, and body, and handle the characteristics (like SQL SECURITY) separately... and then reassemble the CREATE string for parsing, of course. This is rather ugly, mostly the parser bit. (Hopefully that will be better with the new parser.)
2003-12-12 14:05:29 +01:00
const char *params, *returns, *body;
Most of the groundwork for sprint task 729 (implement FUNCTIONs). Expanded the mysql.proc table, reworked the find/create/drop functions completely, added new functions for FUNCTIONs (lotta functions here :), got rid of some unnecessary use of Item_strings while at it. Extended the parser correspondingly, and fiddled around a bit to make SP FUNCTIONs coexist with UDFs. Can now CREATE and DROP FUNCTIONs. Invoking yet to come...
2003-02-21 17:37:05 +01:00
int ret;
WL#1365: Implement definer's rights execution of stored procedures. (Also put the hostpart back in the definer column.)
2003-12-13 16:40:52 +01:00
const char *definer;
Expand the mysql.proc table
2003-05-06 18:09:20 +02:00
longlong created;
longlong modified;
WL#1365: Implement definer's rights execution of stored procedures. (Also put the hostpart back in the definer column.)
2003-12-13 16:40:52 +01:00
st_sp_chistics chistics;
Expand the mysql.proc table
2003-05-06 18:09:20 +02:00
char *ptr;
uint length;
char buff[65];
Code cleanup (and moved sp cache to separate file).
2003-07-03 15:58:37 +02:00
String str(buff, sizeof(buff), &my_charset_bin);
Bug #30604: different flagging of time_zone_used in normal and ps-protocol Finding a routine should be a transparent operation as far as the binary log is concerned. But it was influencing the binary log because of the TIMESTAMP column in the proc table. Fixed by preserving and restoring the time_zone usage flag when searching for a stored routine in the proc table.
2008-02-19 16:27:18 +01:00
bool saved_time_zone_used= thd->time_zone_used;
Bug#32633 Can not create any routine if SQL_MODE=no_engine_substitution The problem is that one can not create a stored routine if sql_mode contains NO_ENGINE_SUBSTITUTION or PAD_CHAR_TO_FULL_LENGTH. Also when a event is created, the mode is silently lost if sql_mode contains one of the aforementioned. This was happening because the table definitions which stored sql_mode values weren't being updated to accept new values of sql_mode. The solution is to update, in a backwards compatible manner, the various table definitions (columns) that store the sql_mode value to take into account the new possible values. One incompatible change is that if a event that is being created can't be stored to the mysql.event table, an error will be raised. The tests case also ensure that new SQL modes will be added to the mysql.proc and mysql.event tables, otherwise the tests will fail.
2008-02-07 11:47:39 +01:00
ulong sql_mode, saved_mode= thd->variables.sql_mode;
Fix for bug #10055 "Using stored function with information_schema causes empty result set". To enable full access to contents of I_S tables from stored functions or statements that use them, we manipulate with thread's open tables state and ensure that we won't cause deadlock when we open tables by ignoring flushes and name-locks. Building of contents of I_S.TABLES no longer requires locking of tables since we use use handler::info() method with HA_STATUS_AUTO flag instead of handler::update_auto_increment() for obtaining information about auto-increment values. But this also means that handlers have to implement support for HA_STATUS_AUTO flag (particularly InnoDB needs it).
2005-08-08 15:46:06 +02:00
Open_tables_state open_tables_state_backup;
Patch for the following bugs: - BUG#11986: Stored routines and triggers can fail if the code has a non-ascii symbol - BUG#16291: mysqldump corrupts string-constants with non-ascii-chars - BUG#19443: INFORMATION_SCHEMA does not support charsets properly - BUG#21249: Character set of SP-var can be ignored - BUG#25212: Character set of string constant is ignored (stored routines) - BUG#25221: Character set of string constant is ignored (triggers) There were a few general problems that caused these bugs: 1. Character set information of the original (definition) query for views, triggers, stored routines and events was lost. 2. mysqldump output query in client character set, which can be inappropriate to encode definition-query. 3. INFORMATION_SCHEMA used strings with mixed encodings to display object definition; 1. No query-definition-character set. In order to compile query into execution code, some extra data (such as environment variables or the database character set) is used. The problem here was that this context was not preserved. So, on the next load it can differ from the original one, thus the result will be different. The context contains the following data: - client character set; - connection collation (character set and collation); - collation of the owner database; The fix is to store this context and use it each time we parse (compile) and execute the object (stored routine, trigger, ...). 2. Wrong mysqldump-output. The original query can contain several encodings (by means of character set introducers). The problem here was that we tried to convert original query to the mysqldump-client character set. Moreover, we stored queries in different character sets for different objects (views, for one, used UTF8, triggers used original character set). The solution is - to store definition queries in the original character set; - to change SHOW CREATE statement to output definition query in the binary character set (i.e. without any conversion); - introduce SHOW CREATE TRIGGER statement; - to dump special statements to switch the context to the original one before dumping and restore it afterwards. Note, in order to preserve the database collation at the creation time, additional ALTER DATABASE might be used (to temporary switch the database collation back to the original value). In this case, ALTER DATABASE privilege will be required. This is a backward-incompatible change. 3. INFORMATION_SCHEMA showed non-UTF8 strings The fix is to generate UTF8-query during the parsing, store it in the object and show it in the INFORMATION_SCHEMA. Basically, the idea is to create a copy of the original query convert it to UTF8. Character set introducers are removed and all text literals are converted to UTF8. This UTF8 query is intended to provide user-readable output. It must not be used to recreate the object. Specialized SHOW CREATE statements should be used for this. The reason for this limitation is the following: the original query can contain symbols from several character sets (by means of character set introducers). Example: - original query: CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1; - UTF8 query (for INFORMATION_SCHEMA): CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 19:34:54 +02:00
Stored_program_creation_ctx *creation_ctx;
Fixed memory leaks in SP Some code cleanup
2003-12-21 11:48:03 +01:00
DBUG_ENTER("db_find_routine");
Fix use of "%*s" *printf() specifiers that were really meant to be "%.*s". (Bug #13650)
2005-10-07 02:37:24 +02:00
DBUG_PRINT("enter", ("type: %d name: %.*s",
WL#3817: Simplify string / memory area types and make things more consistent (first part) The following type conversions was done: - Changed byte to uchar - Changed gptr to uchar* - Change my_string to char * - Change my_size_t to size_t - Change size_s to size_t Removed declaration of byte, gptr, my_string, my_size_t and size_s. Following function parameter changes was done: - All string functions in mysys/strings was changed to use size_t instead of uint for string lengths. - All read()/write() functions changed to use size_t (including vio). - All protocoll functions changed to use size_t instead of uint - Functions that used a pointer to a string length was changed to use size_t* - Changed malloc(), free() and related functions from using gptr to use void * as this requires fewer casts in the code and is more in line with how the standard functions work. - Added extra length argument to dirname_part() to return the length of the created string. - Changed (at least) following functions to take uchar* as argument: - db_dump() - my_net_write() - net_write_command() - net_store_data() - DBUG_DUMP() - decimal2bin() & bin2decimal() - Changed my_compress() and my_uncompress() to use size_t. Changed one argument to my_uncompress() from a pointer to a value as we only return one value (makes function easier to use). - Changed type of 'pack_data' argument to packfrm() to avoid casts. - Changed in readfrm() and writefrom(), ha_discover and handler::discover() the type for argument 'frmdata' to uchar** to avoid casts. - Changed most Field functions to use uchar* instead of char* (reduced a lot of casts). - Changed field->val_xxx(xxx, new_ptr) to take const pointers. Other changes: - Removed a lot of not needed casts - Added a few new cast required by other changes - Added some cast to my_multi_malloc() arguments for safety (as string lengths needs to be uint, not size_t). - Fixed all calls to hash-get-key functions to use size_t*. (Needed to be done explicitely as this conflict was often hided by casting the function to hash_get_key). - Changed some buffers to memory regions to uchar* to avoid casts. - Changed some string lengths from uint to size_t. - Changed field->ptr to be uchar* instead of char*. This allowed us to get rid of a lot of casts. - Some changes from true -> TRUE, false -> FALSE, unsigned char -> uchar - Include zlib.h in some files as we needed declaration of crc32() - Changed MY_FILE_ERROR to be (size_t) -1. - Changed many variables to hold the result of my_read() / my_write() to be size_t. This was needed to properly detect errors (which are returned as (size_t) -1). - Removed some very old VMS code - Changed packfrm()/unpackfrm() to not be depending on uint size (portability fix) - Removed windows specific code to restore cursor position as this causes slowdown on windows and we should not mix read() and pread() calls anyway as this is not thread safe. Updated function comment to reflect this. Changed function that depended on original behavior of my_pwrite() to itself restore the cursor position (one such case). - Added some missing checking of return value of malloc(). - Changed definition of MOD_PAD_CHAR_TO_FULL_LENGTH to avoid 'long' overflow. - Changed type of table_def::m_size from my_size_t to ulong to reflect that m_size is the number of elements in the array, not a string/memory length. - Moved THD::max_row_length() to table.cc (as it's not depending on THD). Inlined max_row_length_blob() into this function. - More function comments - Fixed some compiler warnings when compiled without partitions. - Removed setting of LEX_STRING() arguments in declaration (portability fix). - Some trivial indentation/variable name changes. - Some trivial code simplifications: - Replaced some calls to alloc_root + memcpy to use strmake_root()/strdup_root(). - Changed some calls from memdup() to strmake() (Safety fix) - Simpler loops in client-simple.c
2007-05-10 11:59:39 +02:00
type, (int) name->m_name.length, name->m_name.str));
Moved create/find/drop functions to a separate files (sp.cc,sp.h). Fixed backpatching of forward jumps. Implemented LOOP, WHILE, REPEAT (temporarily known as SPREPEAT). Known bug: Expression evaluation still not quite ok (e.g. "x > 0"), which is why IF and CASE is not yet implemented.
2002-12-12 13:14:23 +01:00
Implementation of Monty's idea: Now we can open mysql.proc table for lookup of stored routines definitions even if we already have some tables open and locked. To avoid deadlocks in this case we have to put certain restrictions on locking of mysql.proc table. This allows to use stored routines safely under LOCK TABLES without explicitly mentioning mysql.proc in the list of locked tables. It also fixes bug #11554 "Server crashes on statement indirectly using non-cached function".
2005-07-13 11:48:13 +02:00
*sphp= 0; // In case of errors
Fix for bug #10055 "Using stored function with information_schema causes empty result set". To enable full access to contents of I_S tables from stored functions or statements that use them, we manipulate with thread's open tables state and ensure that we won't cause deadlock when we open tables by ignoring flushes and name-locks. Building of contents of I_S.TABLES no longer requires locking of tables since we use use handler::info() method with HA_STATUS_AUTO flag instead of handler::update_auto_increment() for obtaining information about auto-increment values. But this also means that handlers have to implement support for HA_STATUS_AUTO flag (particularly InnoDB needs it).
2005-08-08 15:46:06 +02:00
if (!(table= open_proc_table_for_read(thd, &open_tables_state_backup)))
Implementation of Monty's idea: Now we can open mysql.proc table for lookup of stored routines definitions even if we already have some tables open and locked. To avoid deadlocks in this case we have to put certain restrictions on locking of mysql.proc table. This allows to use stored routines safely under LOCK TABLES without explicitly mentioning mysql.proc in the list of locked tables. It also fixes bug #11554 "Server crashes on statement indirectly using non-cached function".
2005-07-13 11:48:13 +02:00
DBUG_RETURN(SP_OPEN_TABLE_FAILED);
Bug#32633 Can not create any routine if SQL_MODE=no_engine_substitution The problem is that one can not create a stored routine if sql_mode contains NO_ENGINE_SUBSTITUTION or PAD_CHAR_TO_FULL_LENGTH. Also when a event is created, the mode is silently lost if sql_mode contains one of the aforementioned. This was happening because the table definitions which stored sql_mode values weren't being updated to accept new values of sql_mode. The solution is to update, in a backwards compatible manner, the various table definitions (columns) that store the sql_mode value to take into account the new possible values. One incompatible change is that if a event that is being created can't be stored to the mysql.event table, an error will be raised. The tests case also ensure that new SQL modes will be added to the mysql.proc and mysql.event tables, otherwise the tests will fail.
2008-02-07 11:47:39 +01:00
/* Reset sql_mode during data dictionary operations. */
thd->variables.sql_mode= 0;
Implementation of Monty's idea: Now we can open mysql.proc table for lookup of stored routines definitions even if we already have some tables open and locked. To avoid deadlocks in this case we have to put certain restrictions on locking of mysql.proc table. This allows to use stored routines safely under LOCK TABLES without explicitly mentioning mysql.proc in the list of locked tables. It also fixes bug #11554 "Server crashes on statement indirectly using non-cached function".
2005-07-13 11:48:13 +02:00
if ((ret= db_find_routine_aux(thd, type, name, table)) != SP_OK)
Most of the groundwork for sprint task 729 (implement FUNCTIONs). Expanded the mysql.proc table, reworked the find/create/drop functions completely, added new functions for FUNCTIONs (lotta functions here :), got rid of some unnecessary use of Item_strings while at it. Extended the parser correspondingly, and fiddled around a bit to make SP FUNCTIONs coexist with UDFs. Can now CREATE and DROP FUNCTIONs. Invoking yet to come...
2003-02-21 17:37:05 +01:00
goto done;
Added more error handling for abnormal cases (like a broken mysql.proc table).
2003-10-30 10:25:45 +01:00
Allow mysql.proc to have extra (unknown) fields. This allows 5.0 to work with 5.1 databases.
2007-07-25 16:38:52 +02:00
if (table->s->fields < MYSQL_PROC_FIELD_COUNT)
Added more error handling for abnormal cases (like a broken mysql.proc table).
2003-10-30 10:25:45 +01:00
{
ret= SP_GET_FIELD_FAILED;
goto done;
}
Implemented the stored procedure data access characteristics: NO SQL CONTAINS SQL (default) READS SQL DATA MODIFIES SQL DATA These are needed as hints for the replication. (Before this, we did have the default in the mysql.proc table, but no support in the parser.)
2004-10-14 18:07:09 +02:00
bzero((char *)&chistics, sizeof(chistics));
After merge fixes Added push_back(void *, MEM_ROOT *) to make some list-handling code easier that needs to be allocated in a different mem-root (Before one had to change thd->mem_root ; push_back(); restore mem_root.
2004-11-09 02:58:44 +01:00
if ((ptr= get_field(thd->mem_root,
Implemented the stored procedure data access characteristics: NO SQL CONTAINS SQL (default) READS SQL DATA MODIFIES SQL DATA These are needed as hints for the replication. (Before this, we did have the default in the mysql.proc table, but no support in the parser.)
2004-10-14 18:07:09 +02:00
table->field[MYSQL_PROC_FIELD_ACCESS])) == NULL)
{
ret= SP_GET_FIELD_FAILED;
goto done;
}
switch (ptr[0]) {
case 'N':
chistics.daccess= SP_NO_SQL;
break;
case 'C':
chistics.daccess= SP_CONTAINS_SQL;
break;
case 'R':
chistics.daccess= SP_READS_SQL_DATA;
break;
case 'M':
chistics.daccess= SP_MODIFIES_SQL_DATA;
break;
default:
Approximative fixes for BUG#2610,2611,9100 i.e. WL#2146 binlogging/replication of routines (stored procs and functions). Approximative, because it's using our binlogging way (what we call "query"-level) and this is not as good as record-level binlog (5.1) would be. It imposes several limitations to routines, and has caveats (which I'll document, and for which the server will try to issue errors but that is not always possible). Reason I don't propagate caller info to the binlog as planned is that on master and slave users may be different; even with that some caveats would remain.
2005-05-05 14:20:53 +02:00
chistics.daccess= SP_DEFAULT_ACCESS_MAPPING;
Implemented the stored procedure data access characteristics: NO SQL CONTAINS SQL (default) READS SQL DATA MODIFIES SQL DATA These are needed as hints for the replication. (Before this, we did have the default in the mysql.proc table, but no support in the parser.)
2004-10-14 18:07:09 +02:00
}
After merge fixes Added push_back(void *, MEM_ROOT *) to make some list-handling code easier that needs to be allocated in a different mem-root (Before one had to change thd->mem_root ; push_back(); restore mem_root.
2004-11-09 02:58:44 +01:00
if ((ptr= get_field(thd->mem_root,
In order to make ALTER PROCEDURE|FUNCTION work correctly, and in general to make characteristics (and SHOW) work right, we had to separate the old definition blob in the mysql.proc table into separate fields for parameters, return type, and body, and handle the characteristics (like SQL SECURITY) separately... and then reassemble the CREATE string for parsing, of course. This is rather ugly, mostly the parser bit. (Hopefully that will be better with the new parser.)
2003-12-12 14:05:29 +01:00
table->field[MYSQL_PROC_FIELD_DETERMINISTIC])) == NULL)
Most of the groundwork for sprint task 729 (implement FUNCTIONs). Expanded the mysql.proc table, reworked the find/create/drop functions completely, added new functions for FUNCTIONs (lotta functions here :), got rid of some unnecessary use of Item_strings while at it. Extended the parser correspondingly, and fiddled around a bit to make SP FUNCTIONs coexist with UDFs. Can now CREATE and DROP FUNCTIONs. Invoking yet to come...
2003-02-21 17:37:05 +01:00
{
ret= SP_GET_FIELD_FAILED;
goto done;
}
WL#1365: Implement definer's rights execution of stored procedures. (Also put the hostpart back in the definer column.)
2003-12-13 16:40:52 +01:00
chistics.detistic= (ptr[0] == 'N' ? FALSE : TRUE);
Expand the mysql.proc table
2003-05-06 18:09:20 +02:00
After merge fixes Added push_back(void *, MEM_ROOT *) to make some list-handling code easier that needs to be allocated in a different mem-root (Before one had to change thd->mem_root ; push_back(); restore mem_root.
2004-11-09 02:58:44 +01:00
if ((ptr= get_field(thd->mem_root,
In order to make ALTER PROCEDURE|FUNCTION work correctly, and in general to make characteristics (and SHOW) work right, we had to separate the old definition blob in the mysql.proc table into separate fields for parameters, return type, and body, and handle the characteristics (like SQL SECURITY) separately... and then reassemble the CREATE string for parsing, of course. This is rather ugly, mostly the parser bit. (Hopefully that will be better with the new parser.)
2003-12-12 14:05:29 +01:00
table->field[MYSQL_PROC_FIELD_SECURITY_TYPE])) == NULL)
Expand the mysql.proc table
2003-05-06 18:09:20 +02:00
{
ret= SP_GET_FIELD_FAILED;
goto done;
}
Implemented the stored procedure data access characteristics: NO SQL CONTAINS SQL (default) READS SQL DATA MODIFIES SQL DATA These are needed as hints for the replication. (Before this, we did have the default in the mysql.proc table, but no support in the parser.)
2004-10-14 18:07:09 +02:00
chistics.suid= (ptr[0] == 'I' ? SP_IS_NOT_SUID : SP_IS_SUID);
Expand the mysql.proc table
2003-05-06 18:09:20 +02:00
After merge fixes Added push_back(void *, MEM_ROOT *) to make some list-handling code easier that needs to be allocated in a different mem-root (Before one had to change thd->mem_root ; push_back(); restore mem_root.
2004-11-09 02:58:44 +01:00
if ((params= get_field(thd->mem_root,
In order to make ALTER PROCEDURE|FUNCTION work correctly, and in general to make characteristics (and SHOW) work right, we had to separate the old definition blob in the mysql.proc table into separate fields for parameters, return type, and body, and handle the characteristics (like SQL SECURITY) separately... and then reassemble the CREATE string for parsing, of course. This is rather ugly, mostly the parser bit. (Hopefully that will be better with the new parser.)
2003-12-12 14:05:29 +01:00
table->field[MYSQL_PROC_FIELD_PARAM_LIST])) == NULL)
{
params= "";
}
Expand the mysql.proc table
2003-05-06 18:09:20 +02:00
In order to make ALTER PROCEDURE|FUNCTION work correctly, and in general to make characteristics (and SHOW) work right, we had to separate the old definition blob in the mysql.proc table into separate fields for parameters, return type, and body, and handle the characteristics (like SQL SECURITY) separately... and then reassemble the CREATE string for parsing, of course. This is rather ugly, mostly the parser bit. (Hopefully that will be better with the new parser.)
2003-12-12 14:05:29 +01:00
if (type == TYPE_ENUM_PROCEDURE)
returns= "";
After merge fixes Added push_back(void *, MEM_ROOT *) to make some list-handling code easier that needs to be allocated in a different mem-root (Before one had to change thd->mem_root ; push_back(); restore mem_root.
2004-11-09 02:58:44 +01:00
else if ((returns= get_field(thd->mem_root,
In order to make ALTER PROCEDURE|FUNCTION work correctly, and in general to make characteristics (and SHOW) work right, we had to separate the old definition blob in the mysql.proc table into separate fields for parameters, return type, and body, and handle the characteristics (like SQL SECURITY) separately... and then reassemble the CREATE string for parsing, of course. This is rather ugly, mostly the parser bit. (Hopefully that will be better with the new parser.)
2003-12-12 14:05:29 +01:00
table->field[MYSQL_PROC_FIELD_RETURNS])) == NULL)
{
ret= SP_GET_FIELD_FAILED;
goto done;
}
After merge fixes Added push_back(void *, MEM_ROOT *) to make some list-handling code easier that needs to be allocated in a different mem-root (Before one had to change thd->mem_root ; push_back(); restore mem_root.
2004-11-09 02:58:44 +01:00
if ((body= get_field(thd->mem_root,
In order to make ALTER PROCEDURE|FUNCTION work correctly, and in general to make characteristics (and SHOW) work right, we had to separate the old definition blob in the mysql.proc table into separate fields for parameters, return type, and body, and handle the characteristics (like SQL SECURITY) separately... and then reassemble the CREATE string for parsing, of course. This is rather ugly, mostly the parser bit. (Hopefully that will be better with the new parser.)
2003-12-12 14:05:29 +01:00
table->field[MYSQL_PROC_FIELD_BODY])) == NULL)
Expand the mysql.proc table
2003-05-06 18:09:20 +02:00
{
ret= SP_GET_FIELD_FAILED;
goto done;
}
In order to make ALTER PROCEDURE|FUNCTION work correctly, and in general to make characteristics (and SHOW) work right, we had to separate the old definition blob in the mysql.proc table into separate fields for parameters, return type, and body, and handle the characteristics (like SQL SECURITY) separately... and then reassemble the CREATE string for parsing, of course. This is rather ugly, mostly the parser bit. (Hopefully that will be better with the new parser.)
2003-12-12 14:05:29 +01:00
// Get additional information
After merge fixes Added push_back(void *, MEM_ROOT *) to make some list-handling code easier that needs to be allocated in a different mem-root (Before one had to change thd->mem_root ; push_back(); restore mem_root.
2004-11-09 02:58:44 +01:00
if ((definer= get_field(thd->mem_root,
In order to make ALTER PROCEDURE|FUNCTION work correctly, and in general to make characteristics (and SHOW) work right, we had to separate the old definition blob in the mysql.proc table into separate fields for parameters, return type, and body, and handle the characteristics (like SQL SECURITY) separately... and then reassemble the CREATE string for parsing, of course. This is rather ugly, mostly the parser bit. (Hopefully that will be better with the new parser.)
2003-12-12 14:05:29 +01:00
table->field[MYSQL_PROC_FIELD_DEFINER])) == NULL)
{
ret= SP_GET_FIELD_FAILED;
goto done;
}
modified= table->field[MYSQL_PROC_FIELD_MODIFIED]->val_int();
created= table->field[MYSQL_PROC_FIELD_CREATED]->val_int();
Expand the mysql.proc table
2003-05-06 18:09:20 +02:00
Update for VC++ (Fixed project files, compiler warnings etc..)
2003-12-21 01:07:45 +01:00
sql_mode= (ulong) table->field[MYSQL_PROC_FIELD_SQL_MODE]->val_int();
WL#1364: Store some environmental values with SPs and use at invokation sql_mode is stored and used with SPs. sql_select_limit is always unlimited in SPs.
2003-12-11 12:23:50 +01:00
Added more error handling for abnormal cases (like a broken mysql.proc table).
2003-10-30 10:25:45 +01:00
table->field[MYSQL_PROC_FIELD_COMMENT]->val_str(&str, &str);
Expand the mysql.proc table
2003-05-06 18:09:20 +02:00
ptr= 0;
'Expand the mysql.proc table to include (almost) all fields' task(851) Fix after review
2003-06-02 11:25:01 +02:00
if ((length= str.length()))
In order to make ALTER PROCEDURE|FUNCTION work correctly, and in general to make characteristics (and SHOW) work right, we had to separate the old definition blob in the mysql.proc table into separate fields for parameters, return type, and body, and handle the characteristics (like SQL SECURITY) separately... and then reassemble the CREATE string for parsing, of course. This is rather ugly, mostly the parser bit. (Hopefully that will be better with the new parser.)
2003-12-12 14:05:29 +01:00
ptr= thd->strmake(str.ptr(), length);
WL#1365: Implement definer's rights execution of stored procedures. (Also put the hostpart back in the definer column.)
2003-12-13 16:40:52 +01:00
chistics.comment.str= ptr;
chistics.comment.length= length;
Expand the mysql.proc table
2003-05-06 18:09:20 +02:00
Patch for the following bugs: - BUG#11986: Stored routines and triggers can fail if the code has a non-ascii symbol - BUG#16291: mysqldump corrupts string-constants with non-ascii-chars - BUG#19443: INFORMATION_SCHEMA does not support charsets properly - BUG#21249: Character set of SP-var can be ignored - BUG#25212: Character set of string constant is ignored (stored routines) - BUG#25221: Character set of string constant is ignored (triggers) There were a few general problems that caused these bugs: 1. Character set information of the original (definition) query for views, triggers, stored routines and events was lost. 2. mysqldump output query in client character set, which can be inappropriate to encode definition-query. 3. INFORMATION_SCHEMA used strings with mixed encodings to display object definition; 1. No query-definition-character set. In order to compile query into execution code, some extra data (such as environment variables or the database character set) is used. The problem here was that this context was not preserved. So, on the next load it can differ from the original one, thus the result will be different. The context contains the following data: - client character set; - connection collation (character set and collation); - collation of the owner database; The fix is to store this context and use it each time we parse (compile) and execute the object (stored routine, trigger, ...). 2. Wrong mysqldump-output. The original query can contain several encodings (by means of character set introducers). The problem here was that we tried to convert original query to the mysqldump-client character set. Moreover, we stored queries in different character sets for different objects (views, for one, used UTF8, triggers used original character set). The solution is - to store definition queries in the original character set; - to change SHOW CREATE statement to output definition query in the binary character set (i.e. without any conversion); - introduce SHOW CREATE TRIGGER statement; - to dump special statements to switch the context to the original one before dumping and restore it afterwards. Note, in order to preserve the database collation at the creation time, additional ALTER DATABASE might be used (to temporary switch the database collation back to the original value). In this case, ALTER DATABASE privilege will be required. This is a backward-incompatible change. 3. INFORMATION_SCHEMA showed non-UTF8 strings The fix is to generate UTF8-query during the parsing, store it in the object and show it in the INFORMATION_SCHEMA. Basically, the idea is to create a copy of the original query convert it to UTF8. Character set introducers are removed and all text literals are converted to UTF8. This UTF8 query is intended to provide user-readable output. It must not be used to recreate the object. Specialized SHOW CREATE statements should be used for this. The reason for this limitation is the following: the original query can contain symbols from several character sets (by means of character set introducers). Example: - original query: CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1; - UTF8 query (for INFORMATION_SCHEMA): CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 19:34:54 +02:00
creation_ctx= Stored_routine_creation_ctx::load_from_db(thd, name, table);
BUG#9953: CONVERT_TZ requires mysql.time_zone_name to be locked The problem was that some facilities (like CONVERT_TZ() function or server HELP statement) may require implicit access to some tables in 'mysql' database. This access was done by ordinary means of adding such tables to the list of tables the query is going to open. However, if we issued LOCK TABLES before that, we would get "table was not locked" error trying to open such implicit tables. The solution is to treat certain tables as MySQL system tables, like we already do for mysql.proc. Such tables may be opened for reading at any moment regardless of any locks in effect. The cost of this is that system table may be locked for writing only together with other system tables, it is disallowed to lock system tables for writing and have any other lock on any other table. After this patch the following tables are treated as MySQL system tables: mysql.help_category mysql.help_keyword mysql.help_relation mysql.help_topic mysql.proc (it already was) mysql.time_zone mysql.time_zone_leap_second mysql.time_zone_name mysql.time_zone_transition mysql.time_zone_transition_type These tables are now opened with open_system_tables_for_read() and closed with close_system_tables(), or one table may be opened with open_system_table_for_update() and closed with close_thread_tables() (the latter is used for mysql.proc table, which is updated as part of normal MySQL server operation). These functions may be used when some tables were opened and locked already. NOTE: online update of time zone tables is not possible during replication, because there's no time zone cache flush neither on LOCK TABLES, nor on FLUSH TABLES, so the master may serve stale time zone data from cache, while on slave updated data will be loaded from the time zone tables.
2007-03-09 11:12:31 +01:00
close_system_tables(thd, &open_tables_state_backup);
Implementation of Monty's idea: Now we can open mysql.proc table for lookup of stored routines definitions even if we already have some tables open and locked. To avoid deadlocks in this case we have to put certain restrictions on locking of mysql.proc table. This allows to use stored routines safely under LOCK TABLES without explicitly mentioning mysql.proc in the list of locked tables. It also fixes bug #11554 "Server crashes on statement indirectly using non-cached function".
2005-07-13 11:48:13 +02:00
table= 0;
Most of the groundwork for sprint task 729 (implement FUNCTIONs). Expanded the mysql.proc table, reworked the find/create/drop functions completely, added new functions for FUNCTIONs (lotta functions here :), got rid of some unnecessary use of Item_strings while at it. Extended the parser correspondingly, and fiddled around a bit to make SP FUNCTIONs coexist with UDFs. Can now CREATE and DROP FUNCTIONs. Invoking yet to come...
2003-02-21 17:37:05 +01:00
Recursion support made for SP (BUG#10100).
2005-11-23 00:11:19 +01:00
ret= db_load_routine(thd, type, name, sphp,
sql_mode, params, returns, body, chistics,
Patch for the following bugs: - BUG#11986: Stored routines and triggers can fail if the code has a non-ascii symbol - BUG#16291: mysqldump corrupts string-constants with non-ascii-chars - BUG#19443: INFORMATION_SCHEMA does not support charsets properly - BUG#21249: Character set of SP-var can be ignored - BUG#25212: Character set of string constant is ignored (stored routines) - BUG#25221: Character set of string constant is ignored (triggers) There were a few general problems that caused these bugs: 1. Character set information of the original (definition) query for views, triggers, stored routines and events was lost. 2. mysqldump output query in client character set, which can be inappropriate to encode definition-query. 3. INFORMATION_SCHEMA used strings with mixed encodings to display object definition; 1. No query-definition-character set. In order to compile query into execution code, some extra data (such as environment variables or the database character set) is used. The problem here was that this context was not preserved. So, on the next load it can differ from the original one, thus the result will be different. The context contains the following data: - client character set; - connection collation (character set and collation); - collation of the owner database; The fix is to store this context and use it each time we parse (compile) and execute the object (stored routine, trigger, ...). 2. Wrong mysqldump-output. The original query can contain several encodings (by means of character set introducers). The problem here was that we tried to convert original query to the mysqldump-client character set. Moreover, we stored queries in different character sets for different objects (views, for one, used UTF8, triggers used original character set). The solution is - to store definition queries in the original character set; - to change SHOW CREATE statement to output definition query in the binary character set (i.e. without any conversion); - introduce SHOW CREATE TRIGGER statement; - to dump special statements to switch the context to the original one before dumping and restore it afterwards. Note, in order to preserve the database collation at the creation time, additional ALTER DATABASE might be used (to temporary switch the database collation back to the original value). In this case, ALTER DATABASE privilege will be required. This is a backward-incompatible change. 3. INFORMATION_SCHEMA showed non-UTF8 strings The fix is to generate UTF8-query during the parsing, store it in the object and show it in the INFORMATION_SCHEMA. Basically, the idea is to create a copy of the original query convert it to UTF8. Character set introducers are removed and all text literals are converted to UTF8. This UTF8 query is intended to provide user-readable output. It must not be used to recreate the object. Specialized SHOW CREATE statements should be used for this. The reason for this limitation is the following: the original query can contain symbols from several character sets (by means of character set introducers). Example: - original query: CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1; - UTF8 query (for INFORMATION_SCHEMA): CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 19:34:54 +02:00
definer, created, modified, creation_ctx);
Recursion support made for SP (BUG#10100).
2005-11-23 00:11:19 +01:00
done:
Bug #30604: different flagging of time_zone_used in normal and ps-protocol Finding a routine should be a transparent operation as far as the binary log is concerned. But it was influencing the binary log because of the TIMESTAMP column in the proc table. Fixed by preserving and restoring the time_zone usage flag when searching for a stored routine in the proc table.
2008-02-19 16:27:18 +01:00
/*
Restore the time zone flag as the timezone usage in proc table
does not affect replication.
*/
thd->time_zone_used= saved_time_zone_used;
Recursion support made for SP (BUG#10100).
2005-11-23 00:11:19 +01:00
if (table)
BUG#9953: CONVERT_TZ requires mysql.time_zone_name to be locked The problem was that some facilities (like CONVERT_TZ() function or server HELP statement) may require implicit access to some tables in 'mysql' database. This access was done by ordinary means of adding such tables to the list of tables the query is going to open. However, if we issued LOCK TABLES before that, we would get "table was not locked" error trying to open such implicit tables. The solution is to treat certain tables as MySQL system tables, like we already do for mysql.proc. Such tables may be opened for reading at any moment regardless of any locks in effect. The cost of this is that system table may be locked for writing only together with other system tables, it is disallowed to lock system tables for writing and have any other lock on any other table. After this patch the following tables are treated as MySQL system tables: mysql.help_category mysql.help_keyword mysql.help_relation mysql.help_topic mysql.proc (it already was) mysql.time_zone mysql.time_zone_leap_second mysql.time_zone_name mysql.time_zone_transition mysql.time_zone_transition_type These tables are now opened with open_system_tables_for_read() and closed with close_system_tables(), or one table may be opened with open_system_table_for_update() and closed with close_thread_tables() (the latter is used for mysql.proc table, which is updated as part of normal MySQL server operation). These functions may be used when some tables were opened and locked already. NOTE: online update of time zone tables is not possible during replication, because there's no time zone cache flush neither on LOCK TABLES, nor on FLUSH TABLES, so the master may serve stale time zone data from cache, while on slave updated data will be loaded from the time zone tables.
2007-03-09 11:12:31 +01:00
close_system_tables(thd, &open_tables_state_backup);
Bug#32633 Can not create any routine if SQL_MODE=no_engine_substitution The problem is that one can not create a stored routine if sql_mode contains NO_ENGINE_SUBSTITUTION or PAD_CHAR_TO_FULL_LENGTH. Also when a event is created, the mode is silently lost if sql_mode contains one of the aforementioned. This was happening because the table definitions which stored sql_mode values weren't being updated to accept new values of sql_mode. The solution is to update, in a backwards compatible manner, the various table definitions (columns) that store the sql_mode value to take into account the new possible values. One incompatible change is that if a event that is being created can't be stored to the mysql.event table, an error will be raised. The tests case also ensure that new SQL modes will be added to the mysql.proc and mysql.event tables, otherwise the tests will fail.
2008-02-07 11:47:39 +01:00
thd->variables.sql_mode= saved_mode;
Recursion support made for SP (BUG#10100).
2005-11-23 00:11:19 +01:00
DBUG_RETURN(ret);
}
Fixed memory leaks in SP Some code cleanup
2003-12-21 11:48:03 +01:00
WL#1366: Use the schema (db) associated with an SP. Phase 2: Make SPs belong to a DB, and use qualified names. As a side effect, using USE in an SP is no longer allowed. (It just doesn't work otherwise.)
2004-03-11 17:18:59 +01:00
Bug#21801 SQL exception handlers and warnings The problem is that deprecated syntax warnings were not being suppressed when the stored routine is being parsed for the first execution. It's doesn't make sense to print out deprecated syntax warnings when the routine is being executed because this kind of warning only matters when the routine is being created. The solution is to suppress deprecated syntax warnings when parsing the stored routine for loading into the cache (might mean that the routine is being executed for the first time).
2008-02-04 19:39:55 +01:00
/**
Silence DEPRECATED SYNTAX warnings when loading a stored procedure
into the cache.
*/
struct Silence_deprecated_warning : public Internal_error_handler
{
public:
virtual bool handle_error(uint sql_errno, const char *message,
MYSQL_ERROR::enum_warning_level level,
THD *thd);
};
bool
Silence_deprecated_warning::handle_error(uint sql_errno, const char *message,
MYSQL_ERROR::enum_warning_level level,
THD *thd)
{
if (sql_errno == ER_WARN_DEPRECATED_SYNTAX &&
level == MYSQL_ERROR::WARN_LEVEL_WARN)
return TRUE;
return FALSE;
}
Recursion support made for SP (BUG#10100).
2005-11-23 00:11:19 +01:00
static int
db_load_routine(THD *thd, int type, sp_name *name, sp_head **sphp,
ulong sql_mode, const char *params, const char *returns,
const char *body, st_sp_chistics &chistics,
Patch for the following bugs: - BUG#11986: Stored routines and triggers can fail if the code has a non-ascii symbol - BUG#16291: mysqldump corrupts string-constants with non-ascii-chars - BUG#19443: INFORMATION_SCHEMA does not support charsets properly - BUG#21249: Character set of SP-var can be ignored - BUG#25212: Character set of string constant is ignored (stored routines) - BUG#25221: Character set of string constant is ignored (triggers) There were a few general problems that caused these bugs: 1. Character set information of the original (definition) query for views, triggers, stored routines and events was lost. 2. mysqldump output query in client character set, which can be inappropriate to encode definition-query. 3. INFORMATION_SCHEMA used strings with mixed encodings to display object definition; 1. No query-definition-character set. In order to compile query into execution code, some extra data (such as environment variables or the database character set) is used. The problem here was that this context was not preserved. So, on the next load it can differ from the original one, thus the result will be different. The context contains the following data: - client character set; - connection collation (character set and collation); - collation of the owner database; The fix is to store this context and use it each time we parse (compile) and execute the object (stored routine, trigger, ...). 2. Wrong mysqldump-output. The original query can contain several encodings (by means of character set introducers). The problem here was that we tried to convert original query to the mysqldump-client character set. Moreover, we stored queries in different character sets for different objects (views, for one, used UTF8, triggers used original character set). The solution is - to store definition queries in the original character set; - to change SHOW CREATE statement to output definition query in the binary character set (i.e. without any conversion); - introduce SHOW CREATE TRIGGER statement; - to dump special statements to switch the context to the original one before dumping and restore it afterwards. Note, in order to preserve the database collation at the creation time, additional ALTER DATABASE might be used (to temporary switch the database collation back to the original value). In this case, ALTER DATABASE privilege will be required. This is a backward-incompatible change. 3. INFORMATION_SCHEMA showed non-UTF8 strings The fix is to generate UTF8-query during the parsing, store it in the object and show it in the INFORMATION_SCHEMA. Basically, the idea is to create a copy of the original query convert it to UTF8. Character set introducers are removed and all text literals are converted to UTF8. This UTF8 query is intended to provide user-readable output. It must not be used to recreate the object. Specialized SHOW CREATE statements should be used for this. The reason for this limitation is the following: the original query can contain symbols from several character sets (by means of character set introducers). Example: - original query: CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1; - UTF8 query (for INFORMATION_SCHEMA): CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 19:34:54 +02:00
const char *definer, longlong created, longlong modified,
Stored_program_creation_ctx *creation_ctx)
Recursion support made for SP (BUG#10100).
2005-11-23 00:11:19 +01:00
{
Review fixes of new pushed code - Fixed tests - Optimized new code - Fixed some unlikely core dumps - Better bug fixes for: - #14397 - OPTIMIZE TABLE with an open HANDLER causes a crash - #14850 (ERROR 1062 when a quering a view using a Group By on a column that can be null
2006-01-05 23:47:49 +01:00
LEX *old_lex= thd->lex, newlex;
Recursion support made for SP (BUG#10100).
2005-11-23 00:11:19 +01:00
String defstr;
Fix for BUG#25843: changing default database between PREPARE and EXECUTE of statement breaks binlog. There were two problems discovered by this bug: 1. Default (current) database is not fixed at the creation time. That leads to wrong output of DATABASE() function. 2. Database attributes (@@collation_database) are not fixed at the creation time. That leads to wrong resultset. Binlog breakage and Query Cache wrong output happened because of the first problem. The fix is to remember the current database at the PREPARE-time and set it each time at EXECUTE.
2007-08-31 18:42:14 +02:00
char saved_cur_db_name_buf[NAME_LEN+1];
LEX_STRING saved_cur_db_name=
{ saved_cur_db_name_buf, sizeof(saved_cur_db_name_buf) };
bool cur_db_changed;
Recursion support made for SP (BUG#10100).
2005-11-23 00:11:19 +01:00
ulong old_sql_mode= thd->variables.sql_mode;
Review fixes of new pushed code - Fixed tests - Optimized new code - Fixed some unlikely core dumps - Better bug fixes for: - #14397 - OPTIMIZE TABLE with an open HANDLER causes a crash - #14850 (ERROR 1062 when a quering a view using a Group By on a column that can be null
2006-01-05 23:47:49 +01:00
ha_rows old_select_limit= thd->variables.select_limit;
sp_rcontext *old_spcont= thd->spcont;
Bug#21801 SQL exception handlers and warnings The problem is that deprecated syntax warnings were not being suppressed when the stored routine is being parsed for the first execution. It's doesn't make sense to print out deprecated syntax warnings when the routine is being executed because this kind of warning only matters when the routine is being created. The solution is to suppress deprecated syntax warnings when parsing the stored routine for loading into the cache (might mean that the routine is being executed for the first time).
2008-02-04 19:39:55 +01:00
Silence_deprecated_warning warning_handler;
after merge fix
2006-09-27 16:21:29 +02:00
char definer_user_name_holder[USERNAME_LENGTH + 1];
Merge maint2.mysql.com:/data/localhome/tsmith/bk/mrg50/50 into maint2.mysql.com:/data/localhome/tsmith/bk/mrg50/51
2006-09-13 09:03:52 +02:00
LEX_STRING definer_user_name= { definer_user_name_holder,
after merge fix
2006-09-28 15:00:44 +02:00
USERNAME_LENGTH };
Implementation of WL#2897: Complete definer support in the stored routines. The idea is to add DEFINER-clause in CREATE PROCEDURE and CREATE FUNCTION statements. Almost all support of definer in stored routines had been already done before this patch. NOTE: this patch changes behaviour of dumping stored routines in mysqldump. Before this patch, mysqldump did not dump DEFINER-clause for stored routines and this was documented behaviour. In order to get full information about stored routines, one should have dumped mysql.proc table. This patch changes this behaviour, so that DEFINER-clause is dumped. Since DEFINER-clause is not supported in CREATE PROCEDURE | FUNCTION statements before this patch, the clause is covered by additional version-specific comments.
2006-03-02 13:18:49 +01:00
char definer_host_name_holder[HOSTNAME_LENGTH + 1];
This is an implementation of two WL items: - WL#3158: IM: Instance configuration extensions; - WL#3159: IM: --bootstrap and --start-default-instance modes The following new statements have been added: - CREATE INSTANCE; - DROP INSTANCE; The behaviour of the following statements have been changed: - SET; - UNSET; - FLUSH INSTANCES; - SHOW INSTANCES; - SHOW INSTANCE OPTIONS;
2006-05-18 16:57:50 +02:00
LEX_STRING definer_host_name= { definer_host_name_holder, HOSTNAME_LENGTH };
Review fixes of new pushed code - Fixed tests - Optimized new code - Fixed some unlikely core dumps - Better bug fixes for: - #14397 - OPTIMIZE TABLE with an open HANDLER causes a crash - #14850 (ERROR 1062 when a quering a view using a Group By on a column that can be null
2006-01-05 23:47:49 +01:00
int ret;
Recursion support made for SP (BUG#10100).
2005-11-23 00:11:19 +01:00
thd->variables.sql_mode= sql_mode;
thd->variables.select_limit= HA_POS_ERROR;
thd->lex= &newlex;
newlex.current_select= NULL;
Implementation of WL#2897: Complete definer support in the stored routines. The idea is to add DEFINER-clause in CREATE PROCEDURE and CREATE FUNCTION statements. Almost all support of definer in stored routines had been already done before this patch. NOTE: this patch changes behaviour of dumping stored routines in mysqldump. Before this patch, mysqldump did not dump DEFINER-clause for stored routines and this was documented behaviour. In order to get full information about stored routines, one should have dumped mysql.proc table. This patch changes this behaviour, so that DEFINER-clause is dumped. Since DEFINER-clause is not supported in CREATE PROCEDURE | FUNCTION statements before this patch, the clause is covered by additional version-specific comments.
2006-03-02 13:18:49 +01:00
parse_user(definer, strlen(definer),
definer_user_name.str, &definer_user_name.length,
definer_host_name.str, &definer_host_name.length);
Patch for the following bugs: - BUG#11986: Stored routines and triggers can fail if the code has a non-ascii symbol - BUG#16291: mysqldump corrupts string-constants with non-ascii-chars - BUG#19443: INFORMATION_SCHEMA does not support charsets properly - BUG#21249: Character set of SP-var can be ignored - BUG#25212: Character set of string constant is ignored (stored routines) - BUG#25221: Character set of string constant is ignored (triggers) There were a few general problems that caused these bugs: 1. Character set information of the original (definition) query for views, triggers, stored routines and events was lost. 2. mysqldump output query in client character set, which can be inappropriate to encode definition-query. 3. INFORMATION_SCHEMA used strings with mixed encodings to display object definition; 1. No query-definition-character set. In order to compile query into execution code, some extra data (such as environment variables or the database character set) is used. The problem here was that this context was not preserved. So, on the next load it can differ from the original one, thus the result will be different. The context contains the following data: - client character set; - connection collation (character set and collation); - collation of the owner database; The fix is to store this context and use it each time we parse (compile) and execute the object (stored routine, trigger, ...). 2. Wrong mysqldump-output. The original query can contain several encodings (by means of character set introducers). The problem here was that we tried to convert original query to the mysqldump-client character set. Moreover, we stored queries in different character sets for different objects (views, for one, used UTF8, triggers used original character set). The solution is - to store definition queries in the original character set; - to change SHOW CREATE statement to output definition query in the binary character set (i.e. without any conversion); - introduce SHOW CREATE TRIGGER statement; - to dump special statements to switch the context to the original one before dumping and restore it afterwards. Note, in order to preserve the database collation at the creation time, additional ALTER DATABASE might be used (to temporary switch the database collation back to the original value). In this case, ALTER DATABASE privilege will be required. This is a backward-incompatible change. 3. INFORMATION_SCHEMA showed non-UTF8 strings The fix is to generate UTF8-query during the parsing, store it in the object and show it in the INFORMATION_SCHEMA. Basically, the idea is to create a copy of the original query convert it to UTF8. Character set introducers are removed and all text literals are converted to UTF8. This UTF8 query is intended to provide user-readable output. It must not be used to recreate the object. Specialized SHOW CREATE statements should be used for this. The reason for this limitation is the following: the original query can contain symbols from several character sets (by means of character set introducers). Example: - original query: CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1; - UTF8 query (for INFORMATION_SCHEMA): CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 19:34:54 +02:00
defstr.set_charset(creation_ctx->get_client_cs());
Implementation of WL#2897: Complete definer support in the stored routines. The idea is to add DEFINER-clause in CREATE PROCEDURE and CREATE FUNCTION statements. Almost all support of definer in stored routines had been already done before this patch. NOTE: this patch changes behaviour of dumping stored routines in mysqldump. Before this patch, mysqldump did not dump DEFINER-clause for stored routines and this was documented behaviour. In order to get full information about stored routines, one should have dumped mysql.proc table. This patch changes this behaviour, so that DEFINER-clause is dumped. Since DEFINER-clause is not supported in CREATE PROCEDURE | FUNCTION statements before this patch, the clause is covered by additional version-specific comments.
2006-03-02 13:18:49 +01:00
/*
We have to add DEFINER clause and provide proper routine characterstics in
routine definition statement that we build here to be able to use this
definition for SHOW CREATE PROCEDURE later.
*/
Recursion support made for SP (BUG#10100).
2005-11-23 00:11:19 +01:00
if (!create_string(thd, &defstr,
Bug#36570: Parse error of CREATE PROCEDURE stmt with comments on \ slave The stored-routine code took the contents of the (lowest) parser and copied it directly to the binlog, which causes problems if there is a special case of interpretation at the parser level -- which there is, in the "/*!VER */" comments. The trailing "*/" caused errors on the slave, naturally. Now, since by that point we have /properly/ created parse-tree (as the rest of the server should do!) for the stored-routine CREATE, we can construct a perfect statement from that information, instead of writing uncertain information from an unknown parser state. Fortunately, there's already a function nearby that does exactly that. --- Update for Bug#36570. Qualify routine names with db name when writing to the binlog ONLY if the source text is qualified.
2008-05-16 01:13:24 +02:00
type,
NULL, 0,
name->m_name.str, name->m_name.length,
params, strlen(params),
returns, strlen(returns),
body, strlen(body),
&chistics, &definer_user_name, &definer_host_name))
Review fixes of new pushed code - Fixed tests - Optimized new code - Fixed some unlikely core dumps - Better bug fixes for: - #14397 - OPTIMIZE TABLE with an open HANDLER causes a crash - #14850 (ERROR 1062 when a quering a view using a Group By on a column that can be null
2006-01-05 23:47:49 +01:00
{
ret= SP_INTERNAL_ERROR;
Recursion support made for SP (BUG#10100).
2005-11-23 00:11:19 +01:00
goto end;
Review fixes of new pushed code - Fixed tests - Optimized new code - Fixed some unlikely core dumps - Better bug fixes for: - #14397 - OPTIMIZE TABLE with an open HANDLER causes a crash - #14850 (ERROR 1062 when a quering a view using a Group By on a column that can be null
2006-01-05 23:47:49 +01:00
}
Fix BUG#2674: Crash if return system variable in stored procedures. Had to initialize some fields in lex before parsing an SP read from mysql.proc.
2004-03-17 12:09:03 +01:00
Patch for the following bugs: - BUG#11986: Stored routines and triggers can fail if the code has a non-ascii symbol - BUG#16291: mysqldump corrupts string-constants with non-ascii-chars - BUG#19443: INFORMATION_SCHEMA does not support charsets properly - BUG#21249: Character set of SP-var can be ignored - BUG#25212: Character set of string constant is ignored (stored routines) - BUG#25221: Character set of string constant is ignored (triggers) There were a few general problems that caused these bugs: 1. Character set information of the original (definition) query for views, triggers, stored routines and events was lost. 2. mysqldump output query in client character set, which can be inappropriate to encode definition-query. 3. INFORMATION_SCHEMA used strings with mixed encodings to display object definition; 1. No query-definition-character set. In order to compile query into execution code, some extra data (such as environment variables or the database character set) is used. The problem here was that this context was not preserved. So, on the next load it can differ from the original one, thus the result will be different. The context contains the following data: - client character set; - connection collation (character set and collation); - collation of the owner database; The fix is to store this context and use it each time we parse (compile) and execute the object (stored routine, trigger, ...). 2. Wrong mysqldump-output. The original query can contain several encodings (by means of character set introducers). The problem here was that we tried to convert original query to the mysqldump-client character set. Moreover, we stored queries in different character sets for different objects (views, for one, used UTF8, triggers used original character set). The solution is - to store definition queries in the original character set; - to change SHOW CREATE statement to output definition query in the binary character set (i.e. without any conversion); - introduce SHOW CREATE TRIGGER statement; - to dump special statements to switch the context to the original one before dumping and restore it afterwards. Note, in order to preserve the database collation at the creation time, additional ALTER DATABASE might be used (to temporary switch the database collation back to the original value). In this case, ALTER DATABASE privilege will be required. This is a backward-incompatible change. 3. INFORMATION_SCHEMA showed non-UTF8 strings The fix is to generate UTF8-query during the parsing, store it in the object and show it in the INFORMATION_SCHEMA. Basically, the idea is to create a copy of the original query convert it to UTF8. Character set introducers are removed and all text literals are converted to UTF8. This UTF8 query is intended to provide user-readable output. It must not be used to recreate the object. Specialized SHOW CREATE statements should be used for this. The reason for this limitation is the following: the original query can contain symbols from several character sets (by means of character set introducers). Example: - original query: CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1; - UTF8 query (for INFORMATION_SCHEMA): CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 19:34:54 +02:00
/*
Fix for BUG#25843: changing default database between PREPARE and EXECUTE of statement breaks binlog. There were two problems discovered by this bug: 1. Default (current) database is not fixed at the creation time. That leads to wrong output of DATABASE() function. 2. Database attributes (@@collation_database) are not fixed at the creation time. That leads to wrong resultset. Binlog breakage and Query Cache wrong output happened because of the first problem. The fix is to remember the current database at the PREPARE-time and set it each time at EXECUTE.
2007-08-31 18:42:14 +02:00
Change the current database (if needed).
Patch for the following bugs: - BUG#11986: Stored routines and triggers can fail if the code has a non-ascii symbol - BUG#16291: mysqldump corrupts string-constants with non-ascii-chars - BUG#19443: INFORMATION_SCHEMA does not support charsets properly - BUG#21249: Character set of SP-var can be ignored - BUG#25212: Character set of string constant is ignored (stored routines) - BUG#25221: Character set of string constant is ignored (triggers) There were a few general problems that caused these bugs: 1. Character set information of the original (definition) query for views, triggers, stored routines and events was lost. 2. mysqldump output query in client character set, which can be inappropriate to encode definition-query. 3. INFORMATION_SCHEMA used strings with mixed encodings to display object definition; 1. No query-definition-character set. In order to compile query into execution code, some extra data (such as environment variables or the database character set) is used. The problem here was that this context was not preserved. So, on the next load it can differ from the original one, thus the result will be different. The context contains the following data: - client character set; - connection collation (character set and collation); - collation of the owner database; The fix is to store this context and use it each time we parse (compile) and execute the object (stored routine, trigger, ...). 2. Wrong mysqldump-output. The original query can contain several encodings (by means of character set introducers). The problem here was that we tried to convert original query to the mysqldump-client character set. Moreover, we stored queries in different character sets for different objects (views, for one, used UTF8, triggers used original character set). The solution is - to store definition queries in the original character set; - to change SHOW CREATE statement to output definition query in the binary character set (i.e. without any conversion); - introduce SHOW CREATE TRIGGER statement; - to dump special statements to switch the context to the original one before dumping and restore it afterwards. Note, in order to preserve the database collation at the creation time, additional ALTER DATABASE might be used (to temporary switch the database collation back to the original value). In this case, ALTER DATABASE privilege will be required. This is a backward-incompatible change. 3. INFORMATION_SCHEMA showed non-UTF8 strings The fix is to generate UTF8-query during the parsing, store it in the object and show it in the INFORMATION_SCHEMA. Basically, the idea is to create a copy of the original query convert it to UTF8. Character set introducers are removed and all text literals are converted to UTF8. This UTF8 query is intended to provide user-readable output. It must not be used to recreate the object. Specialized SHOW CREATE statements should be used for this. The reason for this limitation is the following: the original query can contain symbols from several character sets (by means of character set introducers). Example: - original query: CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1; - UTF8 query (for INFORMATION_SCHEMA): CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 19:34:54 +02:00
Fix for BUG#25843: changing default database between PREPARE and EXECUTE of statement breaks binlog. There were two problems discovered by this bug: 1. Default (current) database is not fixed at the creation time. That leads to wrong output of DATABASE() function. 2. Database attributes (@@collation_database) are not fixed at the creation time. That leads to wrong resultset. Binlog breakage and Query Cache wrong output happened because of the first problem. The fix is to remember the current database at the PREPARE-time and set it each time at EXECUTE.
2007-08-31 18:42:14 +02:00
TODO: why do we force switch here?
Patch for the following bugs: - BUG#11986: Stored routines and triggers can fail if the code has a non-ascii symbol - BUG#16291: mysqldump corrupts string-constants with non-ascii-chars - BUG#19443: INFORMATION_SCHEMA does not support charsets properly - BUG#21249: Character set of SP-var can be ignored - BUG#25212: Character set of string constant is ignored (stored routines) - BUG#25221: Character set of string constant is ignored (triggers) There were a few general problems that caused these bugs: 1. Character set information of the original (definition) query for views, triggers, stored routines and events was lost. 2. mysqldump output query in client character set, which can be inappropriate to encode definition-query. 3. INFORMATION_SCHEMA used strings with mixed encodings to display object definition; 1. No query-definition-character set. In order to compile query into execution code, some extra data (such as environment variables or the database character set) is used. The problem here was that this context was not preserved. So, on the next load it can differ from the original one, thus the result will be different. The context contains the following data: - client character set; - connection collation (character set and collation); - collation of the owner database; The fix is to store this context and use it each time we parse (compile) and execute the object (stored routine, trigger, ...). 2. Wrong mysqldump-output. The original query can contain several encodings (by means of character set introducers). The problem here was that we tried to convert original query to the mysqldump-client character set. Moreover, we stored queries in different character sets for different objects (views, for one, used UTF8, triggers used original character set). The solution is - to store definition queries in the original character set; - to change SHOW CREATE statement to output definition query in the binary character set (i.e. without any conversion); - introduce SHOW CREATE TRIGGER statement; - to dump special statements to switch the context to the original one before dumping and restore it afterwards. Note, in order to preserve the database collation at the creation time, additional ALTER DATABASE might be used (to temporary switch the database collation back to the original value). In this case, ALTER DATABASE privilege will be required. This is a backward-incompatible change. 3. INFORMATION_SCHEMA showed non-UTF8 strings The fix is to generate UTF8-query during the parsing, store it in the object and show it in the INFORMATION_SCHEMA. Basically, the idea is to create a copy of the original query convert it to UTF8. Character set introducers are removed and all text literals are converted to UTF8. This UTF8 query is intended to provide user-readable output. It must not be used to recreate the object. Specialized SHOW CREATE statements should be used for this. The reason for this limitation is the following: the original query can contain symbols from several character sets (by means of character set introducers). Example: - original query: CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1; - UTF8 query (for INFORMATION_SCHEMA): CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 19:34:54 +02:00
*/
Fix for BUG#25843: changing default database between PREPARE and EXECUTE of statement breaks binlog. There were two problems discovered by this bug: 1. Default (current) database is not fixed at the creation time. That leads to wrong output of DATABASE() function. 2. Database attributes (@@collation_database) are not fixed at the creation time. That leads to wrong resultset. Binlog breakage and Query Cache wrong output happened because of the first problem. The fix is to remember the current database at the PREPARE-time and set it each time at EXECUTE.
2007-08-31 18:42:14 +02:00
if (mysql_opt_change_db(thd, &name->m_db, &saved_cur_db_name, TRUE,
&cur_db_changed))
{
Eliminate compile warnings.
2007-08-31 22:12:00 +02:00
ret= SP_INTERNAL_ERROR;
Recursion support made for SP (BUG#10100).
2005-11-23 00:11:19 +01:00
goto end;
Fix for BUG#25843: changing default database between PREPARE and EXECUTE of statement breaks binlog. There were two problems discovered by this bug: 1. Default (current) database is not fixed at the creation time. That leads to wrong output of DATABASE() function. 2. Database attributes (@@collation_database) are not fixed at the creation time. That leads to wrong resultset. Binlog breakage and Query Cache wrong output happened because of the first problem. The fix is to remember the current database at the PREPARE-time and set it each time at EXECUTE.
2007-08-31 18:42:14 +02:00
}
Bugfixes for the sp_head memroot stuff.
2003-07-01 17:19:48 +02:00
The second cleanup patch in scope of BUG#11986. 1. Introduce parse_sql() as a high-level replacement for MYSQLparse(). parse_sql() is responsible to switch and restore "parser context" (THD::m_lip for now). 2. Fix typo in sp.cc: THD::spcont should be reset *before* calling the parser.
2007-06-14 16:35:59 +02:00
thd->spcont= NULL;
manual merge 5.0-runtime -> 5.1->runtime, with 25411 part I
2007-04-26 05:38:12 +02:00
{
Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on build) The crash was caused by freeing the internal parser stack during the parser execution. This occured only for complex stored procedures, after reallocating the parser stack using my_yyoverflow(), with the following C call stack: - MYSQLparse() - any rule calling sp_head::restore_lex() - lex_end() - x_free(lex->yacc_yyss), xfree(lex->yacc_yyvs) The root cause is the implementation of stored procedures, which breaks the assumption from 4.1 that there is only one LEX structure per parser call. The solution is to separate the LEX structure into: - attributes that represent a statement (the current LEX structure), - attributes that relate to the syntax parser itself (Yacc_state), so that parsing multiple statements in stored programs can create multiple LEX structures while not changing the unique Yacc_state. Now, Yacc_state and the existing Lex_input_stream are aggregated into Parser_state, a structure that represent the complete state of the (Lexical + Syntax) parser.
2008-07-14 23:41:30 +02:00
Parser_state parser_state(thd, defstr.c_ptr(), defstr.length());
Patch for the following bugs: - BUG#11986: Stored routines and triggers can fail if the code has a non-ascii symbol - BUG#16291: mysqldump corrupts string-constants with non-ascii-chars - BUG#19443: INFORMATION_SCHEMA does not support charsets properly - BUG#21249: Character set of SP-var can be ignored - BUG#25212: Character set of string constant is ignored (stored routines) - BUG#25221: Character set of string constant is ignored (triggers) There were a few general problems that caused these bugs: 1. Character set information of the original (definition) query for views, triggers, stored routines and events was lost. 2. mysqldump output query in client character set, which can be inappropriate to encode definition-query. 3. INFORMATION_SCHEMA used strings with mixed encodings to display object definition; 1. No query-definition-character set. In order to compile query into execution code, some extra data (such as environment variables or the database character set) is used. The problem here was that this context was not preserved. So, on the next load it can differ from the original one, thus the result will be different. The context contains the following data: - client character set; - connection collation (character set and collation); - collation of the owner database; The fix is to store this context and use it each time we parse (compile) and execute the object (stored routine, trigger, ...). 2. Wrong mysqldump-output. The original query can contain several encodings (by means of character set introducers). The problem here was that we tried to convert original query to the mysqldump-client character set. Moreover, we stored queries in different character sets for different objects (views, for one, used UTF8, triggers used original character set). The solution is - to store definition queries in the original character set; - to change SHOW CREATE statement to output definition query in the binary character set (i.e. without any conversion); - introduce SHOW CREATE TRIGGER statement; - to dump special statements to switch the context to the original one before dumping and restore it afterwards. Note, in order to preserve the database collation at the creation time, additional ALTER DATABASE might be used (to temporary switch the database collation back to the original value). In this case, ALTER DATABASE privilege will be required. This is a backward-incompatible change. 3. INFORMATION_SCHEMA showed non-UTF8 strings The fix is to generate UTF8-query during the parsing, store it in the object and show it in the INFORMATION_SCHEMA. Basically, the idea is to create a copy of the original query convert it to UTF8. Character set introducers are removed and all text literals are converted to UTF8. This UTF8 query is intended to provide user-readable output. It must not be used to recreate the object. Specialized SHOW CREATE statements should be used for this. The reason for this limitation is the following: the original query can contain symbols from several character sets (by means of character set introducers). Example: - original query: CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1; - UTF8 query (for INFORMATION_SCHEMA): CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 19:34:54 +02:00
manual merge 5.0-runtime -> 5.1->runtime, with 25411 part I
2007-04-26 05:38:12 +02:00
lex_start(thd);
Recursion support made for SP (BUG#10100).
2005-11-23 00:11:19 +01:00
Bug#21801 SQL exception handlers and warnings The problem is that deprecated syntax warnings were not being suppressed when the stored routine is being parsed for the first execution. It's doesn't make sense to print out deprecated syntax warnings when the routine is being executed because this kind of warning only matters when the routine is being created. The solution is to suppress deprecated syntax warnings when parsing the stored routine for loading into the cache (might mean that the routine is being executed for the first time).
2008-02-04 19:39:55 +01:00
thd->push_internal_handler(&warning_handler);
Bug#35577, manual merge mysql-5.0-bugteam -> mysql-5.1-bugteam
2008-07-15 03:43:12 +02:00
ret= parse_sql(thd, & parser_state, creation_ctx) || newlex.sphead == NULL;
Bug#21801 SQL exception handlers and warnings The problem is that deprecated syntax warnings were not being suppressed when the stored routine is being parsed for the first execution. It's doesn't make sense to print out deprecated syntax warnings when the routine is being executed because this kind of warning only matters when the routine is being created. The solution is to suppress deprecated syntax warnings when parsing the stored routine for loading into the cache (might mean that the routine is being executed for the first time).
2008-02-04 19:39:55 +01:00
thd->pop_internal_handler();
The second cleanup patch in scope of BUG#11986. 1. Introduce parse_sql() as a high-level replacement for MYSQLparse(). parse_sql() is responsible to switch and restore "parser context" (THD::m_lip for now). 2. Fix typo in sp.cc: THD::spcont should be reset *before* calling the parser.
2007-06-14 16:35:59 +02:00
Fix for BUG#25843: changing default database between PREPARE and EXECUTE of statement breaks binlog. There were two problems discovered by this bug: 1. Default (current) database is not fixed at the creation time. That leads to wrong output of DATABASE() function. 2. Database attributes (@@collation_database) are not fixed at the creation time. That leads to wrong resultset. Binlog breakage and Query Cache wrong output happened because of the first problem. The fix is to remember the current database at the PREPARE-time and set it each time at EXECUTE.
2007-08-31 18:42:14 +02:00
/*
Force switching back to the saved current database (if changed),
because it may be NULL. In this case, mysql_change_db() would
generate an error.
*/
if (cur_db_changed && mysql_change_db(thd, &saved_cur_db_name, TRUE))
{
delete newlex.sphead;
Eliminate compile warnings.
2007-08-31 22:12:00 +02:00
ret= SP_INTERNAL_ERROR;
Fix for BUG#25843: changing default database between PREPARE and EXECUTE of statement breaks binlog. There were two problems discovered by this bug: 1. Default (current) database is not fixed at the creation time. That leads to wrong output of DATABASE() function. 2. Database attributes (@@collation_database) are not fixed at the creation time. That leads to wrong resultset. Binlog breakage and Query Cache wrong output happened because of the first problem. The fix is to remember the current database at the PREPARE-time and set it each time at EXECUTE.
2007-08-31 18:42:14 +02:00
goto end;
The second cleanup patch in scope of BUG#11986. 1. Introduce parse_sql() as a high-level replacement for MYSQLparse(). parse_sql() is responsible to switch and restore "parser context" (THD::m_lip for now). 2. Fix typo in sp.cc: THD::spcont should be reset *before* calling the parser.
2007-06-14 16:35:59 +02:00
}
Fix for BUG#25843: changing default database between PREPARE and EXECUTE of statement breaks binlog. There were two problems discovered by this bug: 1. Default (current) database is not fixed at the creation time. That leads to wrong output of DATABASE() function. 2. Database attributes (@@collation_database) are not fixed at the creation time. That leads to wrong resultset. Binlog breakage and Query Cache wrong output happened because of the first problem. The fix is to remember the current database at the PREPARE-time and set it each time at EXECUTE.
2007-08-31 18:42:14 +02:00
if (ret)
The second cleanup patch in scope of BUG#11986. 1. Introduce parse_sql() as a high-level replacement for MYSQLparse(). parse_sql() is responsible to switch and restore "parser context" (THD::m_lip for now). 2. Fix typo in sp.cc: THD::spcont should be reset *before* calling the parser.
2007-06-14 16:35:59 +02:00
{
Fix for BUG#25843: changing default database between PREPARE and EXECUTE of statement breaks binlog. There were two problems discovered by this bug: 1. Default (current) database is not fixed at the creation time. That leads to wrong output of DATABASE() function. 2. Database attributes (@@collation_database) are not fixed at the creation time. That leads to wrong resultset. Binlog breakage and Query Cache wrong output happened because of the first problem. The fix is to remember the current database at the PREPARE-time and set it each time at EXECUTE.
2007-08-31 18:42:14 +02:00
delete newlex.sphead;
ret= SP_PARSE_ERROR;
goto end;
The second cleanup patch in scope of BUG#11986. 1. Introduce parse_sql() as a high-level replacement for MYSQLparse(). parse_sql() is responsible to switch and restore "parser context" (THD::m_lip for now). 2. Fix typo in sp.cc: THD::spcont should be reset *before* calling the parser.
2007-06-14 16:35:59 +02:00
}
Fix for BUG#25843: changing default database between PREPARE and EXECUTE of statement breaks binlog. There were two problems discovered by this bug: 1. Default (current) database is not fixed at the creation time. That leads to wrong output of DATABASE() function. 2. Database attributes (@@collation_database) are not fixed at the creation time. That leads to wrong resultset. Binlog breakage and Query Cache wrong output happened because of the first problem. The fix is to remember the current database at the PREPARE-time and set it each time at EXECUTE.
2007-08-31 18:42:14 +02:00
*sphp= newlex.sphead;
(*sphp)->set_definer(&definer_user_name, &definer_host_name);
(*sphp)->set_info(created, modified, &chistics, sql_mode);
(*sphp)->set_creation_ctx(creation_ctx);
(*sphp)->optimize();
/*
Not strictly necessary to invoke this method here, since we know
that we've parsed CREATE PROCEDURE/FUNCTION and not an
UPDATE/DELETE/INSERT/REPLACE/LOAD/CREATE TABLE, but we try to
maintain the invariant that this method is called for each
distinct statement, in case its logic is extended with other
types of analyses in future.
*/
newlex.set_trg_event_type_for_tables();
Recursion support made for SP (BUG#10100).
2005-11-23 00:11:19 +01:00
}
The second cleanup patch in scope of BUG#11986. 1. Introduce parse_sql() as a high-level replacement for MYSQLparse(). parse_sql() is responsible to switch and restore "parser context" (THD::m_lip for now). 2. Fix typo in sp.cc: THD::spcont should be reset *before* calling the parser.
2007-06-14 16:35:59 +02:00
postmerge fix
2005-11-23 01:49:44 +01:00
end:
Fixed memory leak in sql_parse.cc (lex_end() was not called) This caused sp-vars.test to fail
2006-05-04 14:30:38 +02:00
lex_end(thd->lex);
Review fixes of new pushed code - Fixed tests - Optimized new code - Fixed some unlikely core dumps - Better bug fixes for: - #14397 - OPTIMIZE TABLE with an open HANDLER causes a crash - #14850 (ERROR 1062 when a quering a view using a Group By on a column that can be null
2006-01-05 23:47:49 +01:00
thd->spcont= old_spcont;
Recursion support made for SP (BUG#10100).
2005-11-23 00:11:19 +01:00
thd->variables.sql_mode= old_sql_mode;
Review fixes of new pushed code - Fixed tests - Optimized new code - Fixed some unlikely core dumps - Better bug fixes for: - #14397 - OPTIMIZE TABLE with an open HANDLER causes a crash - #14850 (ERROR 1062 when a quering a view using a Group By on a column that can be null
2006-01-05 23:47:49 +01:00
thd->variables.select_limit= old_select_limit;
thd->lex= old_lex;
Recursion support made for SP (BUG#10100).
2005-11-23 00:11:19 +01:00
return ret;
Moved create/find/drop functions to a separate files (sp.cc,sp.h). Fixed backpatching of forward jumps. Implemented LOOP, WHILE, REPEAT (temporarily known as SPREPEAT). Known bug: Expression evaluation still not quite ok (e.g. "x > 0"), which is why IF and CASE is not yet implemented.
2002-12-12 13:14:23 +01:00
}
Fixed memory leaks in SP Some code cleanup
2003-12-21 11:48:03 +01:00
Bug#3788 Crashes with stored procedure return non-string values Also fixes Bug#2773
2005-03-04 22:14:35 +01:00
static void
sp_returns_type(THD *thd, String &result, sp_head *sp)
{
More portability fixes
2005-03-10 20:42:57 +01:00
TABLE table;
Table definition cache, part 2 The table opening process now works the following way: - Create common TABLE_SHARE object - Read the .frm file and unpack it into the TABLE_SHARE object - Create a TABLE object based on the information in the TABLE_SHARE object and open a handler to the table object Other noteworthy changes: - In TABLE_SHARE the most common strings are now LEX_STRING's - Better error message when table is not found - Variable table_cache is now renamed 'table_open_cache' - New variable 'table_definition_cache' that is the number of table defintions that will be cached - strxnmov() calls are now fixed to avoid overflows - strxnmov() will now always add one end \0 to result - engine objects are now created with a TABLE_SHARE object instead of a TABLE object. - After creating a field object one must call field->init(table) before using it - For a busy system this change will give you: - Less memory usage for table object - Faster opening of tables (if it's has been in use or is in table definition cache) - Allow you to cache many table definitions objects - Faster drop of table
2005-11-23 21:45:02 +01:00
TABLE_SHARE share;
Bug#3788 Crashes with stored procedure return non-string values Also fixes Bug#2773
2005-03-04 22:14:35 +01:00
Field *field;
Table definition cache, part 2 The table opening process now works the following way: - Create common TABLE_SHARE object - Read the .frm file and unpack it into the TABLE_SHARE object - Create a TABLE object based on the information in the TABLE_SHARE object and open a handler to the table object Other noteworthy changes: - In TABLE_SHARE the most common strings are now LEX_STRING's - Better error message when table is not found - Variable table_cache is now renamed 'table_open_cache' - New variable 'table_definition_cache' that is the number of table defintions that will be cached - strxnmov() calls are now fixed to avoid overflows - strxnmov() will now always add one end \0 to result - engine objects are now created with a TABLE_SHARE object instead of a TABLE object. - After creating a field object one must call field->init(table) before using it - For a busy system this change will give you: - Less memory usage for table object - Faster opening of tables (if it's has been in use or is in table definition cache) - Allow you to cache many table definitions objects - Faster drop of table
2005-11-23 21:45:02 +01:00
bzero((char*) &table, sizeof(table));
bzero((char*) &share, sizeof(share));
More portability fixes
2005-03-10 20:42:57 +01:00
table.in_use= thd;
Table definition cache, part 2 The table opening process now works the following way: - Create common TABLE_SHARE object - Read the .frm file and unpack it into the TABLE_SHARE object - Create a TABLE object based on the information in the TABLE_SHARE object and open a handler to the table object Other noteworthy changes: - In TABLE_SHARE the most common strings are now LEX_STRING's - Better error message when table is not found - Variable table_cache is now renamed 'table_open_cache' - New variable 'table_definition_cache' that is the number of table defintions that will be cached - strxnmov() calls are now fixed to avoid overflows - strxnmov() will now always add one end \0 to result - engine objects are now created with a TABLE_SHARE object instead of a TABLE object. - After creating a field object one must call field->init(table) before using it - For a busy system this change will give you: - Less memory usage for table object - Faster opening of tables (if it's has been in use or is in table definition cache) - Allow you to cache many table definitions objects - Faster drop of table
2005-11-23 21:45:02 +01:00
table.s = &share;
Patch for WL#2894: Make stored routine variables work according to the standard. The idea is to use Field-classes to implement stored routines variables. Also, we should provide facade to Item-hierarchy by Item_field class (it is necessary, since SRVs take part in expressions). The patch fixes the following bugs: - BUG#8702: Stored Procedures: No Error/Warning shown for inappropriate data type matching; - BUG#8768: Functions: For any unsigned data type, -ve values can be passed and returned; - BUG#8769: Functions: For Int datatypes, out of range values can be passed and returned; - BUG#9078: STORED PROCDURE: Decimal digits are not displayed when we use DECIMAL datatype; - BUG#9572: Stored procedures: variable type declarations ignored; - BUG#12903: upper function does not work inside a function; - BUG#13705: parameters to stored procedures are not verified; - BUG#13808: ENUM type stored procedure parameter accepts non-enumerated data; - BUG#13909: Varchar Stored Procedure Parameter always BINARY string (ignores CHARACTER SET); - BUG#14161: Stored procedure cannot retrieve bigint unsigned; - BUG#14188: BINARY variables have no 0x00 padding; - BUG#15148: Stored procedure variables accept non-scalar values;
2005-12-07 15:01:17 +01:00
field= sp->create_result_field(0, 0, &table);
Bug#3788 Crashes with stored procedure return non-string values Also fixes Bug#2773
2005-03-04 22:14:35 +01:00
field->sql_type(result);
Fix for BUG#16211: Stored function return type for strings is ignored. Fix for BUG#16676: Database CHARSET not used for stored procedures The problem in BUG#16211 is that CHARSET-clause of the return type for stored functions is just ignored. The problem in BUG#16676 is that if character set is not explicitly specified for sp-variable, the server character set is used instead of the database one. The fix has two parts: - always store CHARSET-clause of the return type along with the type definition in mysql.proc.returns column. "Always" means that CHARSET-clause is appended even if it has not been explicitly specified in CREATE FUNCTION statement (this affects BUG#16211 only). Storing CHARSET-clause if it is not specified is essential to avoid changing character set if the database character set is altered in the future. NOTE: this change is not backward compatible with the previous releases. - use database default character set if CHARSET-clause is not explicitly specified (this affects both BUG#16211 and BUG#16676). NOTE: this also breaks backward compatibility.
2006-07-27 15:57:43 +02:00
if (field->has_charset())
{
result.append(STRING_WITH_LEN(" CHARSET "));
result.append(field->charset()->csname);
}
Bug#3788 Crashes with stored procedure return non-string values Also fixes Bug#2773
2005-03-04 22:14:35 +01:00
delete field;
}
Refactoring patch: 1. Refactor sp_show_create_function() and sp_show_create_procedure() into show_create_routine(). 2. Code cleanup: eliminate proxy functions.
2007-05-29 19:22:33 +02:00
/**
Write stored-routine object into mysql.proc.
This operation stores attributes of the stored procedure/function into
the mysql.proc.
@param thd Thread context.
@param type Stored routine type
(TYPE_ENUM_PROCEDURE or TYPE_ENUM_FUNCTION).
@param sp Stored routine object to store.
A fix and a test case for Bug#12713 "Error in a stored function called from a SELECT doesn't cause ROLLBACK of statem". The idea of the fix is to ensure that we always commit the current statement at the end of dispatch_command(). In order to not issue redundant disc syncs, an optimization of the two-phase commit protocol is implemented to bypass the two phase commit if the transaction is read-only.
2008-02-19 12:43:01 +01:00
@note Opens and closes the thread tables. Therefore assumes
that there are no locked tables in this thread at the time of
invocation.
Unlike some other DDL statements, *does* close the tables
in the end, since the call to this function is normally
followed by an implicit grant (sp_grant_privileges())
and this subsequent call opens and closes mysql.procs_priv.
@return Error code. SP_OK is returned on success. Other
SP_ constants are used to indicate about errors.
Refactoring patch: 1. Refactor sp_show_create_function() and sp_show_create_procedure() into show_create_routine(). 2. Code cleanup: eliminate proxy functions.
2007-05-29 19:22:33 +02:00
*/
int
sp_create_routine(THD *thd, int type, sp_head *sp)
Moved create/find/drop functions to a separate files (sp.cc,sp.h). Fixed backpatching of forward jumps. Implemented LOOP, WHILE, REPEAT (temporarily known as SPREPEAT). Known bug: Expression evaluation still not quite ok (e.g. "x > 0"), which is why IF and CASE is not yet implemented.
2002-12-12 13:14:23 +01:00
{
Most of the groundwork for sprint task 729 (implement FUNCTIONs). Expanded the mysql.proc table, reworked the find/create/drop functions completely, added new functions for FUNCTIONs (lotta functions here :), got rid of some unnecessary use of Item_strings while at it. Extended the parser correspondingly, and fiddled around a bit to make SP FUNCTIONs coexist with UDFs. Can now CREATE and DROP FUNCTIONs. Invoking yet to come...
2003-02-21 17:37:05 +01:00
int ret;
Moved create/find/drop functions to a separate files (sp.cc,sp.h). Fixed backpatching of forward jumps. Implemented LOOP, WHILE, REPEAT (temporarily known as SPREPEAT). Known bug: Expression evaluation still not quite ok (e.g. "x > 0"), which is why IF and CASE is not yet implemented.
2002-12-12 13:14:23 +01:00
TABLE *table;
Fix for BUG#15110: mysqldump --triggers: does not include DEFINER clause There are two main idea of this fix: - introduce a common function for server and client to split user value (<user name>@<host name>) into user name and host name parts; - dump DEFINER clause in correct format in mysqldump.
2006-01-11 00:07:40 +01:00
char definer[USER_HOST_BUFF_SIZE];
Bug#32633 Can not create any routine if SQL_MODE=no_engine_substitution The problem is that one can not create a stored routine if sql_mode contains NO_ENGINE_SUBSTITUTION or PAD_CHAR_TO_FULL_LENGTH. Also when a event is created, the mode is silently lost if sql_mode contains one of the aforementioned. This was happening because the table definitions which stored sql_mode values weren't being updated to accept new values of sql_mode. The solution is to update, in a backwards compatible manner, the various table definitions (columns) that store the sql_mode value to take into account the new possible values. One incompatible change is that if a event that is being created can't be stored to the mysql.event table, an error will be raised. The tests case also ensure that new SQL modes will be added to the mysql.proc and mysql.event tables, otherwise the tests will fail.
2008-02-07 11:47:39 +01:00
ulong saved_mode= thd->variables.sql_mode;
Refactoring patch: 1. Refactor sp_show_create_function() and sp_show_create_procedure() into show_create_routine(). 2. Code cleanup: eliminate proxy functions.
2007-05-29 19:22:33 +02:00
Patch for the following bugs: - BUG#11986: Stored routines and triggers can fail if the code has a non-ascii symbol - BUG#16291: mysqldump corrupts string-constants with non-ascii-chars - BUG#19443: INFORMATION_SCHEMA does not support charsets properly - BUG#21249: Character set of SP-var can be ignored - BUG#25212: Character set of string constant is ignored (stored routines) - BUG#25221: Character set of string constant is ignored (triggers) There were a few general problems that caused these bugs: 1. Character set information of the original (definition) query for views, triggers, stored routines and events was lost. 2. mysqldump output query in client character set, which can be inappropriate to encode definition-query. 3. INFORMATION_SCHEMA used strings with mixed encodings to display object definition; 1. No query-definition-character set. In order to compile query into execution code, some extra data (such as environment variables or the database character set) is used. The problem here was that this context was not preserved. So, on the next load it can differ from the original one, thus the result will be different. The context contains the following data: - client character set; - connection collation (character set and collation); - collation of the owner database; The fix is to store this context and use it each time we parse (compile) and execute the object (stored routine, trigger, ...). 2. Wrong mysqldump-output. The original query can contain several encodings (by means of character set introducers). The problem here was that we tried to convert original query to the mysqldump-client character set. Moreover, we stored queries in different character sets for different objects (views, for one, used UTF8, triggers used original character set). The solution is - to store definition queries in the original character set; - to change SHOW CREATE statement to output definition query in the binary character set (i.e. without any conversion); - introduce SHOW CREATE TRIGGER statement; - to dump special statements to switch the context to the original one before dumping and restore it afterwards. Note, in order to preserve the database collation at the creation time, additional ALTER DATABASE might be used (to temporary switch the database collation back to the original value). In this case, ALTER DATABASE privilege will be required. This is a backward-incompatible change. 3. INFORMATION_SCHEMA showed non-UTF8 strings The fix is to generate UTF8-query during the parsing, store it in the object and show it in the INFORMATION_SCHEMA. Basically, the idea is to create a copy of the original query convert it to UTF8. Character set introducers are removed and all text literals are converted to UTF8. This UTF8 query is intended to provide user-readable output. It must not be used to recreate the object. Specialized SHOW CREATE statements should be used for this. The reason for this limitation is the following: the original query can contain symbols from several character sets (by means of character set introducers). Example: - original query: CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1; - UTF8 query (for INFORMATION_SCHEMA): CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 19:34:54 +02:00
CHARSET_INFO *db_cs= get_default_db_collation(thd, sp->m_db.str);
Fix for BUG#24923: Functions with ENUM issues. The problem was that the RETURNS column in the mysql.proc was of CHAR(64). That was not enough for storing long-named datatypes. The fix is to change CHAR(64) to LONGBLOB, and to throw warnings at the time a stored routine is created if some data is truncated during writing into mysql.proc.
2007-10-17 10:13:56 +02:00
enum_check_fields saved_count_cuted_fields;
bool store_failed= FALSE;
Refactoring patch: 1. Refactor sp_show_create_function() and sp_show_create_procedure() into show_create_routine(). 2. Code cleanup: eliminate proxy functions.
2007-05-29 19:22:33 +02:00
DBUG_ENTER("sp_create_routine");
WL#3817: Simplify string / memory area types and make things more consistent (first part) The following type conversions was done: - Changed byte to uchar - Changed gptr to uchar* - Change my_string to char * - Change my_size_t to size_t - Change size_s to size_t Removed declaration of byte, gptr, my_string, my_size_t and size_s. Following function parameter changes was done: - All string functions in mysys/strings was changed to use size_t instead of uint for string lengths. - All read()/write() functions changed to use size_t (including vio). - All protocoll functions changed to use size_t instead of uint - Functions that used a pointer to a string length was changed to use size_t* - Changed malloc(), free() and related functions from using gptr to use void * as this requires fewer casts in the code and is more in line with how the standard functions work. - Added extra length argument to dirname_part() to return the length of the created string. - Changed (at least) following functions to take uchar* as argument: - db_dump() - my_net_write() - net_write_command() - net_store_data() - DBUG_DUMP() - decimal2bin() & bin2decimal() - Changed my_compress() and my_uncompress() to use size_t. Changed one argument to my_uncompress() from a pointer to a value as we only return one value (makes function easier to use). - Changed type of 'pack_data' argument to packfrm() to avoid casts. - Changed in readfrm() and writefrom(), ha_discover and handler::discover() the type for argument 'frmdata' to uchar** to avoid casts. - Changed most Field functions to use uchar* instead of char* (reduced a lot of casts). - Changed field->val_xxx(xxx, new_ptr) to take const pointers. Other changes: - Removed a lot of not needed casts - Added a few new cast required by other changes - Added some cast to my_multi_malloc() arguments for safety (as string lengths needs to be uint, not size_t). - Fixed all calls to hash-get-key functions to use size_t*. (Needed to be done explicitely as this conflict was often hided by casting the function to hash_get_key). - Changed some buffers to memory regions to uchar* to avoid casts. - Changed some string lengths from uint to size_t. - Changed field->ptr to be uchar* instead of char*. This allowed us to get rid of a lot of casts. - Some changes from true -> TRUE, false -> FALSE, unsigned char -> uchar - Include zlib.h in some files as we needed declaration of crc32() - Changed MY_FILE_ERROR to be (size_t) -1. - Changed many variables to hold the result of my_read() / my_write() to be size_t. This was needed to properly detect errors (which are returned as (size_t) -1). - Removed some very old VMS code - Changed packfrm()/unpackfrm() to not be depending on uint size (portability fix) - Removed windows specific code to restore cursor position as this causes slowdown on windows and we should not mix read() and pread() calls anyway as this is not thread safe. Updated function comment to reflect this. Changed function that depended on original behavior of my_pwrite() to itself restore the cursor position (one such case). - Added some missing checking of return value of malloc(). - Changed definition of MOD_PAD_CHAR_TO_FULL_LENGTH to avoid 'long' overflow. - Changed type of table_def::m_size from my_size_t to ulong to reflect that m_size is the number of elements in the array, not a string/memory length. - Moved THD::max_row_length() to table.cc (as it's not depending on THD). Inlined max_row_length_blob() into this function. - More function comments - Fixed some compiler warnings when compiled without partitions. - Removed setting of LEX_STRING() arguments in declaration (portability fix). - Some trivial indentation/variable name changes. - Some trivial code simplifications: - Replaced some calls to alloc_root + memcpy to use strmake_root()/strdup_root(). - Changed some calls from memdup() to strmake() (Safety fix) - Simpler loops in client-simple.c
2007-05-10 11:59:39 +02:00
DBUG_PRINT("enter", ("type: %d name: %.*s",type, (int) sp->m_name.length,
Fix use of "%*s" *printf() specifiers that were really meant to be "%.*s". (Bug #13650)
2005-10-07 02:37:24 +02:00
sp->m_name.str));
Bug#36570: Parse error of CREATE PROCEDURE stmt with comments on \ slave The stored-routine code took the contents of the (lowest) parser and copied it directly to the binlog, which causes problems if there is a special case of interpretation at the parser level -- which there is, in the "/*!VER */" comments. The trailing "*/" caused errors on the slave, naturally. Now, since by that point we have /properly/ created parse-tree (as the rest of the server should do!) for the stored-routine CREATE, we can construct a perfect statement from that information, instead of writing uncertain information from an unknown parser state. Fortunately, there's already a function nearby that does exactly that.
2008-05-15 01:23:54 +02:00
String retstr(64);
Moved create/find/drop functions to a separate files (sp.cc,sp.h). Fixed backpatching of forward jumps. Implemented LOOP, WHILE, REPEAT (temporarily known as SPREPEAT). Known bug: Expression evaluation still not quite ok (e.g. "x > 0"), which is why IF and CASE is not yet implemented.
2002-12-12 13:14:23 +01:00
Refactoring patch: 1. Refactor sp_show_create_function() and sp_show_create_procedure() into show_create_routine(). 2. Code cleanup: eliminate proxy functions.
2007-05-29 19:22:33 +02:00
DBUG_ASSERT(type == TYPE_ENUM_PROCEDURE ||
type == TYPE_ENUM_FUNCTION);
Bug#32633 Can not create any routine if SQL_MODE=no_engine_substitution The problem is that one can not create a stored routine if sql_mode contains NO_ENGINE_SUBSTITUTION or PAD_CHAR_TO_FULL_LENGTH. Also when a event is created, the mode is silently lost if sql_mode contains one of the aforementioned. This was happening because the table definitions which stored sql_mode values weren't being updated to accept new values of sql_mode. The solution is to update, in a backwards compatible manner, the various table definitions (columns) that store the sql_mode value to take into account the new possible values. One incompatible change is that if a event that is being created can't be stored to the mysql.event table, an error will be raised. The tests case also ensure that new SQL modes will be added to the mysql.proc and mysql.event tables, otherwise the tests will fail.
2008-02-07 11:47:39 +01:00
/* Reset sql_mode during data dictionary operations. */
thd->variables.sql_mode= 0;
BUG#25091 (A DELETE statement to mysql database is not logged in ROW format): With this patch, statements that change metadata (in the mysql database) is logged as statements, while normal changes (e.g., using INSERT, DELETE, and/or UPDATE) is logged according to the format in effect. The log tables (i.e., general_log and slow_log) are not replicated at all. With this patch, the following statements are replicated as statements: GRANT, REVOKE (ALL), CREATE USER, DROP USER, and RENAME USER.
2007-02-26 10:19:08 +01:00
/*
This statement will be replicated as a statement, even when using
row-based replication. The flag will be reset at the end of the
statement.
*/
thd->clear_current_stmt_binlog_row_based();
Fix for BUG#24923: Functions with ENUM issues. The problem was that the RETURNS column in the mysql.proc was of CHAR(64). That was not enough for storing long-named datatypes. The fix is to change CHAR(64) to LONGBLOB, and to throw warnings at the time a stored routine is created if some data is truncated during writing into mysql.proc.
2007-10-17 10:13:56 +02:00
saved_count_cuted_fields= thd->count_cuted_fields;
thd->count_cuted_fields= CHECK_FIELD_WARN;
Implementation of Monty's idea: Now we can open mysql.proc table for lookup of stored routines definitions even if we already have some tables open and locked. To avoid deadlocks in this case we have to put certain restrictions on locking of mysql.proc table. This allows to use stored routines safely under LOCK TABLES without explicitly mentioning mysql.proc in the list of locked tables. It also fixes bug #11554 "Server crashes on statement indirectly using non-cached function".
2005-07-13 11:48:13 +02:00
if (!(table= open_proc_table_for_update(thd)))
Most of the groundwork for sprint task 729 (implement FUNCTIONs). Expanded the mysql.proc table, reworked the find/create/drop functions completely, added new functions for FUNCTIONs (lotta functions here :), got rid of some unnecessary use of Item_strings while at it. Extended the parser correspondingly, and fiddled around a bit to make SP FUNCTIONs coexist with UDFs. Can now CREATE and DROP FUNCTIONs. Invoking yet to come...
2003-02-21 17:37:05 +01:00
ret= SP_OPEN_TABLE_FAILED;
else
Moved create/find/drop functions to a separate files (sp.cc,sp.h). Fixed backpatching of forward jumps. Implemented LOOP, WHILE, REPEAT (temporarily known as SPREPEAT). Known bug: Expression evaluation still not quite ok (e.g. "x > 0"), which is why IF and CASE is not yet implemented.
2002-12-12 13:14:23 +01:00
{
First stage of table definition cache Split TABLE to TABLE and TABLE_SHARE (TABLE_SHARE is still allocated as part of table, will be fixed soon) Created Field::make_field() and made Field_num::make_field() to call this Added 'TABLE_SHARE->db' that points to database name; Changed all usage of table_cache_key as database name to use this instead Changed field->table_name to point to pointer to alias. This allows us to change alias for a table by just updating one pointer. Renamed TABLE_SHARE->real_name to table_name Renamed TABLE->table_name to alias Renamed TABLE_LIST->real_name to table_name
2005-01-06 12:00:13 +01:00
restore_record(table, s->default_values); // Get default values for fields
Implementation of WL#2897: Complete definer support in the stored routines. The idea is to add DEFINER-clause in CREATE PROCEDURE and CREATE FUNCTION statements. Almost all support of definer in stored routines had been already done before this patch. NOTE: this patch changes behaviour of dumping stored routines in mysqldump. Before this patch, mysqldump did not dump DEFINER-clause for stored routines and this was documented behaviour. In order to get full information about stored routines, one should have dumped mysql.proc table. This patch changes this behaviour, so that DEFINER-clause is dumped. Since DEFINER-clause is not supported in CREATE PROCEDURE | FUNCTION statements before this patch, the clause is covered by additional version-specific comments.
2006-03-02 13:18:49 +01:00
/* NOTE: all needed privilege checks have been already done. */
Merge mysql.com:/home/alik/Documents/AllProgs/MySQL/devel/5.0-tree into mysql.com:/home/alik/Documents/AllProgs/MySQL/devel/5.1-merged
2006-03-09 18:41:21 +01:00
strxnmov(definer, sizeof(definer)-1, thd->lex->definer->user.str, "@",
Implementation of WL#2897: Complete definer support in the stored routines. The idea is to add DEFINER-clause in CREATE PROCEDURE and CREATE FUNCTION statements. Almost all support of definer in stored routines had been already done before this patch. NOTE: this patch changes behaviour of dumping stored routines in mysqldump. Before this patch, mysqldump did not dump DEFINER-clause for stored routines and this was documented behaviour. In order to get full information about stored routines, one should have dumped mysql.proc table. This patch changes this behaviour, so that DEFINER-clause is dumped. Since DEFINER-clause is not supported in CREATE PROCEDURE | FUNCTION statements before this patch, the clause is covered by additional version-specific comments.
2006-03-02 13:18:49 +01:00
thd->lex->definer->host.str, NullS);
Most of the groundwork for sprint task 729 (implement FUNCTIONs). Expanded the mysql.proc table, reworked the find/create/drop functions completely, added new functions for FUNCTIONs (lotta functions here :), got rid of some unnecessary use of Item_strings while at it. Extended the parser correspondingly, and fiddled around a bit to make SP FUNCTIONs coexist with UDFs. Can now CREATE and DROP FUNCTIONs. Invoking yet to come...
2003-02-21 17:37:05 +01:00
Allow mysql.proc to have extra (unknown) fields. This allows 5.0 to work with 5.1 databases.
2007-07-25 16:38:52 +02:00
if (table->s->fields < MYSQL_PROC_FIELD_COUNT)
Added more error handling for abnormal cases (like a broken mysql.proc table).
2003-10-30 10:25:45 +01:00
{
ret= SP_GET_FIELD_FAILED;
goto done;
}
Fixed BUG#17015: Routine name truncation not an error The name length was checked "the old way", not taking charsets into account, when creating a stored routine. Fixing this enforces the real limit (64 characters) again, and no truncation is possible.
2006-02-16 13:40:37 +01:00
Review fix for BUG#17015: Routine name truncation not an error
2006-03-28 15:06:06 +02:00
if (system_charset_info->cset->numchars(system_charset_info,
sp->m_name.str,
sp->m_name.str+sp->m_name.length) >
table->field[MYSQL_PROC_FIELD_NAME]->char_length())
Fixed BUG#9529: Stored Procedures: No Warning on truncation of procedure name during creation. Although it returns an error, consistent with the behaviour for other objects. (Unclear why we would allow the creation of SPs with truncated names.)
2005-05-31 18:36:32 +02:00
{
ret= SP_BAD_IDENTIFIER;
goto done;
}
Increase allowed size of stored procedure bodies to 4GB, and produce a sensible error when that limit is exceeded. (Bug #11602)
2005-07-27 03:08:49 +02:00
if (sp->m_body.length > table->field[MYSQL_PROC_FIELD_BODY]->field_length)
{
ret= SP_BODY_TOO_LONG;
goto done;
}
Fix for BUG#24923: Functions with ENUM issues. The problem was that the RETURNS column in the mysql.proc was of CHAR(64). That was not enough for storing long-named datatypes. The fix is to change CHAR(64) to LONGBLOB, and to throw warnings at the time a stored routine is created if some data is truncated during writing into mysql.proc.
2007-10-17 10:13:56 +02:00
store_failed=
table->field[MYSQL_PROC_FIELD_DB]->
store(sp->m_db.str, sp->m_db.length, system_charset_info);
store_failed= store_failed ||
table->field[MYSQL_PROC_FIELD_NAME]->
store(sp->m_name.str, sp->m_name.length, system_charset_info);
store_failed= store_failed ||
table->field[MYSQL_PROC_MYSQL_TYPE]->
store((longlong)type, TRUE);
store_failed= store_failed ||
table->field[MYSQL_PROC_FIELD_SPECIFIC_NAME]->
store(sp->m_name.str, sp->m_name.length, system_charset_info);
Implemented the stored procedure data access characteristics: NO SQL CONTAINS SQL (default) READS SQL DATA MODIFIES SQL DATA These are needed as hints for the replication. (Before this, we did have the default in the mysql.proc table, but no support in the parser.)
2004-10-14 18:07:09 +02:00
if (sp->m_chistics->daccess != SP_DEFAULT_ACCESS)
Fix for BUG#24923: Functions with ENUM issues. The problem was that the RETURNS column in the mysql.proc was of CHAR(64). That was not enough for storing long-named datatypes. The fix is to change CHAR(64) to LONGBLOB, and to throw warnings at the time a stored routine is created if some data is truncated during writing into mysql.proc.
2007-10-17 10:13:56 +02:00
{
store_failed= store_failed ||
table->field[MYSQL_PROC_FIELD_ACCESS]->
store((longlong)sp->m_chistics->daccess, TRUE);
}
store_failed= store_failed ||
table->field[MYSQL_PROC_FIELD_DETERMINISTIC]->
store((longlong)(sp->m_chistics->detistic ? 1 : 2), TRUE);
Implemented the stored procedure data access characteristics: NO SQL CONTAINS SQL (default) READS SQL DATA MODIFIES SQL DATA These are needed as hints for the replication. (Before this, we did have the default in the mysql.proc table, but no support in the parser.)
2004-10-14 18:07:09 +02:00
if (sp->m_chistics->suid != SP_IS_DEFAULT_SUID)
Fix for BUG#24923: Functions with ENUM issues. The problem was that the RETURNS column in the mysql.proc was of CHAR(64). That was not enough for storing long-named datatypes. The fix is to change CHAR(64) to LONGBLOB, and to throw warnings at the time a stored routine is created if some data is truncated during writing into mysql.proc.
2007-10-17 10:13:56 +02:00
{
store_failed= store_failed ||
table->field[MYSQL_PROC_FIELD_SECURITY_TYPE]->
store((longlong)sp->m_chistics->suid, TRUE);
}
store_failed= store_failed ||
table->field[MYSQL_PROC_FIELD_PARAM_LIST]->
store(sp->m_params.str, sp->m_params.length, system_charset_info);
Bug#3788 Crashes with stored procedure return non-string values Also fixes Bug#2773
2005-03-04 22:14:35 +01:00
if (sp->m_type == TYPE_ENUM_FUNCTION)
{
sp_returns_type(thd, retstr, sp);
Fix for BUG#24923: Functions with ENUM issues. The problem was that the RETURNS column in the mysql.proc was of CHAR(64). That was not enough for storing long-named datatypes. The fix is to change CHAR(64) to LONGBLOB, and to throw warnings at the time a stored routine is created if some data is truncated during writing into mysql.proc.
2007-10-17 10:13:56 +02:00
store_failed= store_failed ||
table->field[MYSQL_PROC_FIELD_RETURNS]->
store(retstr.ptr(), retstr.length(), system_charset_info);
Bug#3788 Crashes with stored procedure return non-string values Also fixes Bug#2773
2005-03-04 22:14:35 +01:00
}
Fix for BUG#24923: Functions with ENUM issues. The problem was that the RETURNS column in the mysql.proc was of CHAR(64). That was not enough for storing long-named datatypes. The fix is to change CHAR(64) to LONGBLOB, and to throw warnings at the time a stored routine is created if some data is truncated during writing into mysql.proc.
2007-10-17 10:13:56 +02:00
store_failed= store_failed ||
table->field[MYSQL_PROC_FIELD_BODY]->
store(sp->m_body.str, sp->m_body.length, system_charset_info);
store_failed= store_failed ||
table->field[MYSQL_PROC_FIELD_DEFINER]->
store(definer, (uint)strlen(definer), system_charset_info);
Added more error handling for abnormal cases (like a broken mysql.proc table).
2003-10-30 10:25:45 +01:00
((Field_timestamp *)table->field[MYSQL_PROC_FIELD_CREATED])->set_time();
Fixed BUG#5258: Stored procedure modified date is 0000-00-00. Althought techically not a but (as it's functioning as designed), it was decided that the design should be changed. Some users have a problem with dates being '0000-00-00' and the SQL standard specifies that the modification date should be the same as the creation date at creation.
2004-09-08 11:42:18 +02:00
((Field_timestamp *)table->field[MYSQL_PROC_FIELD_MODIFIED])->set_time();
Fix for BUG#24923: Functions with ENUM issues. The problem was that the RETURNS column in the mysql.proc was of CHAR(64). That was not enough for storing long-named datatypes. The fix is to change CHAR(64) to LONGBLOB, and to throw warnings at the time a stored routine is created if some data is truncated during writing into mysql.proc.
2007-10-17 10:13:56 +02:00
store_failed= store_failed ||
table->field[MYSQL_PROC_FIELD_SQL_MODE]->
Bug#32633 Can not create any routine if SQL_MODE=no_engine_substitution The problem is that one can not create a stored routine if sql_mode contains NO_ENGINE_SUBSTITUTION or PAD_CHAR_TO_FULL_LENGTH. Also when a event is created, the mode is silently lost if sql_mode contains one of the aforementioned. This was happening because the table definitions which stored sql_mode values weren't being updated to accept new values of sql_mode. The solution is to update, in a backwards compatible manner, the various table definitions (columns) that store the sql_mode value to take into account the new possible values. One incompatible change is that if a event that is being created can't be stored to the mysql.event table, an error will be raised. The tests case also ensure that new SQL modes will be added to the mysql.proc and mysql.event tables, otherwise the tests will fail.
2008-02-07 11:47:39 +01:00
store((longlong)saved_mode, TRUE);
Fix for BUG#24923: Functions with ENUM issues. The problem was that the RETURNS column in the mysql.proc was of CHAR(64). That was not enough for storing long-named datatypes. The fix is to change CHAR(64) to LONGBLOB, and to throw warnings at the time a stored routine is created if some data is truncated during writing into mysql.proc.
2007-10-17 10:13:56 +02:00
In order to make ALTER PROCEDURE|FUNCTION work correctly, and in general to make characteristics (and SHOW) work right, we had to separate the old definition blob in the mysql.proc table into separate fields for parameters, return type, and body, and handle the characteristics (like SQL SECURITY) separately... and then reassemble the CREATE string for parsing, of course. This is rather ugly, mostly the parser bit. (Hopefully that will be better with the new parser.)
2003-12-12 14:05:29 +01:00
if (sp->m_chistics->comment.str)
Fix for BUG#24923: Functions with ENUM issues. The problem was that the RETURNS column in the mysql.proc was of CHAR(64). That was not enough for storing long-named datatypes. The fix is to change CHAR(64) to LONGBLOB, and to throw warnings at the time a stored routine is created if some data is truncated during writing into mysql.proc.
2007-10-17 10:13:56 +02:00
{
store_failed= store_failed ||
table->field[MYSQL_PROC_FIELD_COMMENT]->
store(sp->m_chistics->comment.str, sp->m_chistics->comment.length,
system_charset_info);
}
Most of the groundwork for sprint task 729 (implement FUNCTIONs). Expanded the mysql.proc table, reworked the find/create/drop functions completely, added new functions for FUNCTIONs (lotta functions here :), got rid of some unnecessary use of Item_strings while at it. Extended the parser correspondingly, and fiddled around a bit to make SP FUNCTIONs coexist with UDFs. Can now CREATE and DROP FUNCTIONs. Invoking yet to come...
2003-02-21 17:37:05 +01:00
WL#2971 "change log-bin-trust-routine-creators=0 to apply only to functions". Indeed now that stored procedures CALL is not binlogged, but instead the invoked substatements are, the restrictions applied by log-bin-trust-routine-creators=0 are superfluous for procedures. They still need to apply to functions where function calls are written to the binlog (for example as "DO myfunc(3)"). We rename the variable to log-bin-trust-function-creators but allow the old name until some future version (and issue a warning if old name is used).
2005-11-10 17:50:51 +01:00
if ((sp->m_type == TYPE_ENUM_FUNCTION) &&
!trust_function_creators && mysql_bin_log.is_open())
Approximative fixes for BUG#2610,2611,9100 i.e. WL#2146 binlogging/replication of routines (stored procs and functions). Approximative, because it's using our binlogging way (what we call "query"-level) and this is not as good as record-level binlog (5.1) would be. It imposes several limitations to routines, and has caveats (which I'll document, and for which the server will try to issue errors but that is not always possible). Reason I don't propagate caller info to the binlog as planned is that on master and slave users may be different; even with that some caveats would remain.
2005-05-05 14:20:53 +02:00
{
if (!sp->m_chistics->detistic)
{
/*
WL#2971 "change log-bin-trust-routine-creators=0 to apply only to functions". Indeed now that stored procedures CALL is not binlogged, but instead the invoked substatements are, the restrictions applied by log-bin-trust-routine-creators=0 are superfluous for procedures. They still need to apply to functions where function calls are written to the binlog (for example as "DO myfunc(3)"). We rename the variable to log-bin-trust-function-creators but allow the old name until some future version (and issue a warning if old name is used).
2005-11-10 17:50:51 +01:00
Note that this test is not perfect; one could use
Approximative fixes for BUG#2610,2611,9100 i.e. WL#2146 binlogging/replication of routines (stored procs and functions). Approximative, because it's using our binlogging way (what we call "query"-level) and this is not as good as record-level binlog (5.1) would be. It imposes several limitations to routines, and has caveats (which I'll document, and for which the server will try to issue errors but that is not always possible). Reason I don't propagate caller info to the binlog as planned is that on master and slave users may be different; even with that some caveats would remain.
2005-05-05 14:20:53 +02:00
a non-deterministic read-only function in an update statement.
*/
enum enum_sp_data_access access=
(sp->m_chistics->daccess == SP_DEFAULT_ACCESS) ?
SP_DEFAULT_ACCESS_MAPPING : sp->m_chistics->daccess;
if (access == SP_CONTAINS_SQL ||
access == SP_MODIFIES_SQL_DATA)
{
my_message(ER_BINLOG_UNSAFE_ROUTINE,
ER(ER_BINLOG_UNSAFE_ROUTINE), MYF(0));
ret= SP_INTERNAL_ERROR;
goto done;
}
}
WL#2787 (part 2, ver 3 (merged)) changed securety context switching
2005-09-15 21:29:07 +02:00
if (!(thd->security_ctx->master_access & SUPER_ACL))
Approximative fixes for BUG#2610,2611,9100 i.e. WL#2146 binlogging/replication of routines (stored procs and functions). Approximative, because it's using our binlogging way (what we call "query"-level) and this is not as good as record-level binlog (5.1) would be. It imposes several limitations to routines, and has caveats (which I'll document, and for which the server will try to issue errors but that is not always possible). Reason I don't propagate caller info to the binlog as planned is that on master and slave users may be different; even with that some caveats would remain.
2005-05-05 14:20:53 +02:00
{
my_message(ER_BINLOG_CREATE_ROUTINE_NEED_SUPER,
ER(ER_BINLOG_CREATE_ROUTINE_NEED_SUPER), MYF(0));
ret= SP_INTERNAL_ERROR;
goto done;
}
}
Patch for the following bugs: - BUG#11986: Stored routines and triggers can fail if the code has a non-ascii symbol - BUG#16291: mysqldump corrupts string-constants with non-ascii-chars - BUG#19443: INFORMATION_SCHEMA does not support charsets properly - BUG#21249: Character set of SP-var can be ignored - BUG#25212: Character set of string constant is ignored (stored routines) - BUG#25221: Character set of string constant is ignored (triggers) There were a few general problems that caused these bugs: 1. Character set information of the original (definition) query for views, triggers, stored routines and events was lost. 2. mysqldump output query in client character set, which can be inappropriate to encode definition-query. 3. INFORMATION_SCHEMA used strings with mixed encodings to display object definition; 1. No query-definition-character set. In order to compile query into execution code, some extra data (such as environment variables or the database character set) is used. The problem here was that this context was not preserved. So, on the next load it can differ from the original one, thus the result will be different. The context contains the following data: - client character set; - connection collation (character set and collation); - collation of the owner database; The fix is to store this context and use it each time we parse (compile) and execute the object (stored routine, trigger, ...). 2. Wrong mysqldump-output. The original query can contain several encodings (by means of character set introducers). The problem here was that we tried to convert original query to the mysqldump-client character set. Moreover, we stored queries in different character sets for different objects (views, for one, used UTF8, triggers used original character set). The solution is - to store definition queries in the original character set; - to change SHOW CREATE statement to output definition query in the binary character set (i.e. without any conversion); - introduce SHOW CREATE TRIGGER statement; - to dump special statements to switch the context to the original one before dumping and restore it afterwards. Note, in order to preserve the database collation at the creation time, additional ALTER DATABASE might be used (to temporary switch the database collation back to the original value). In this case, ALTER DATABASE privilege will be required. This is a backward-incompatible change. 3. INFORMATION_SCHEMA showed non-UTF8 strings The fix is to generate UTF8-query during the parsing, store it in the object and show it in the INFORMATION_SCHEMA. Basically, the idea is to create a copy of the original query convert it to UTF8. Character set introducers are removed and all text literals are converted to UTF8. This UTF8 query is intended to provide user-readable output. It must not be used to recreate the object. Specialized SHOW CREATE statements should be used for this. The reason for this limitation is the following: the original query can contain symbols from several character sets (by means of character set introducers). Example: - original query: CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1; - UTF8 query (for INFORMATION_SCHEMA): CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 19:34:54 +02:00
table->field[MYSQL_PROC_FIELD_CHARACTER_SET_CLIENT]->set_notnull();
Fix for BUG#24923: Functions with ENUM issues. The problem was that the RETURNS column in the mysql.proc was of CHAR(64). That was not enough for storing long-named datatypes. The fix is to change CHAR(64) to LONGBLOB, and to throw warnings at the time a stored routine is created if some data is truncated during writing into mysql.proc.
2007-10-17 10:13:56 +02:00
store_failed= store_failed ||
table->field[MYSQL_PROC_FIELD_CHARACTER_SET_CLIENT]->store(
thd->charset()->csname,
strlen(thd->charset()->csname),
system_charset_info);
Patch for the following bugs: - BUG#11986: Stored routines and triggers can fail if the code has a non-ascii symbol - BUG#16291: mysqldump corrupts string-constants with non-ascii-chars - BUG#19443: INFORMATION_SCHEMA does not support charsets properly - BUG#21249: Character set of SP-var can be ignored - BUG#25212: Character set of string constant is ignored (stored routines) - BUG#25221: Character set of string constant is ignored (triggers) There were a few general problems that caused these bugs: 1. Character set information of the original (definition) query for views, triggers, stored routines and events was lost. 2. mysqldump output query in client character set, which can be inappropriate to encode definition-query. 3. INFORMATION_SCHEMA used strings with mixed encodings to display object definition; 1. No query-definition-character set. In order to compile query into execution code, some extra data (such as environment variables or the database character set) is used. The problem here was that this context was not preserved. So, on the next load it can differ from the original one, thus the result will be different. The context contains the following data: - client character set; - connection collation (character set and collation); - collation of the owner database; The fix is to store this context and use it each time we parse (compile) and execute the object (stored routine, trigger, ...). 2. Wrong mysqldump-output. The original query can contain several encodings (by means of character set introducers). The problem here was that we tried to convert original query to the mysqldump-client character set. Moreover, we stored queries in different character sets for different objects (views, for one, used UTF8, triggers used original character set). The solution is - to store definition queries in the original character set; - to change SHOW CREATE statement to output definition query in the binary character set (i.e. without any conversion); - introduce SHOW CREATE TRIGGER statement; - to dump special statements to switch the context to the original one before dumping and restore it afterwards. Note, in order to preserve the database collation at the creation time, additional ALTER DATABASE might be used (to temporary switch the database collation back to the original value). In this case, ALTER DATABASE privilege will be required. This is a backward-incompatible change. 3. INFORMATION_SCHEMA showed non-UTF8 strings The fix is to generate UTF8-query during the parsing, store it in the object and show it in the INFORMATION_SCHEMA. Basically, the idea is to create a copy of the original query convert it to UTF8. Character set introducers are removed and all text literals are converted to UTF8. This UTF8 query is intended to provide user-readable output. It must not be used to recreate the object. Specialized SHOW CREATE statements should be used for this. The reason for this limitation is the following: the original query can contain symbols from several character sets (by means of character set introducers). Example: - original query: CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1; - UTF8 query (for INFORMATION_SCHEMA): CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 19:34:54 +02:00
table->field[MYSQL_PROC_FIELD_COLLATION_CONNECTION]->set_notnull();
Fix for BUG#24923: Functions with ENUM issues. The problem was that the RETURNS column in the mysql.proc was of CHAR(64). That was not enough for storing long-named datatypes. The fix is to change CHAR(64) to LONGBLOB, and to throw warnings at the time a stored routine is created if some data is truncated during writing into mysql.proc.
2007-10-17 10:13:56 +02:00
store_failed= store_failed ||
table->field[MYSQL_PROC_FIELD_COLLATION_CONNECTION]->store(
thd->variables.collation_connection->name,
strlen(thd->variables.collation_connection->name),
system_charset_info);
Patch for the following bugs: - BUG#11986: Stored routines and triggers can fail if the code has a non-ascii symbol - BUG#16291: mysqldump corrupts string-constants with non-ascii-chars - BUG#19443: INFORMATION_SCHEMA does not support charsets properly - BUG#21249: Character set of SP-var can be ignored - BUG#25212: Character set of string constant is ignored (stored routines) - BUG#25221: Character set of string constant is ignored (triggers) There were a few general problems that caused these bugs: 1. Character set information of the original (definition) query for views, triggers, stored routines and events was lost. 2. mysqldump output query in client character set, which can be inappropriate to encode definition-query. 3. INFORMATION_SCHEMA used strings with mixed encodings to display object definition; 1. No query-definition-character set. In order to compile query into execution code, some extra data (such as environment variables or the database character set) is used. The problem here was that this context was not preserved. So, on the next load it can differ from the original one, thus the result will be different. The context contains the following data: - client character set; - connection collation (character set and collation); - collation of the owner database; The fix is to store this context and use it each time we parse (compile) and execute the object (stored routine, trigger, ...). 2. Wrong mysqldump-output. The original query can contain several encodings (by means of character set introducers). The problem here was that we tried to convert original query to the mysqldump-client character set. Moreover, we stored queries in different character sets for different objects (views, for one, used UTF8, triggers used original character set). The solution is - to store definition queries in the original character set; - to change SHOW CREATE statement to output definition query in the binary character set (i.e. without any conversion); - introduce SHOW CREATE TRIGGER statement; - to dump special statements to switch the context to the original one before dumping and restore it afterwards. Note, in order to preserve the database collation at the creation time, additional ALTER DATABASE might be used (to temporary switch the database collation back to the original value). In this case, ALTER DATABASE privilege will be required. This is a backward-incompatible change. 3. INFORMATION_SCHEMA showed non-UTF8 strings The fix is to generate UTF8-query during the parsing, store it in the object and show it in the INFORMATION_SCHEMA. Basically, the idea is to create a copy of the original query convert it to UTF8. Character set introducers are removed and all text literals are converted to UTF8. This UTF8 query is intended to provide user-readable output. It must not be used to recreate the object. Specialized SHOW CREATE statements should be used for this. The reason for this limitation is the following: the original query can contain symbols from several character sets (by means of character set introducers). Example: - original query: CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1; - UTF8 query (for INFORMATION_SCHEMA): CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 19:34:54 +02:00
table->field[MYSQL_PROC_FIELD_DB_COLLATION]->set_notnull();
Fix for BUG#24923: Functions with ENUM issues. The problem was that the RETURNS column in the mysql.proc was of CHAR(64). That was not enough for storing long-named datatypes. The fix is to change CHAR(64) to LONGBLOB, and to throw warnings at the time a stored routine is created if some data is truncated during writing into mysql.proc.
2007-10-17 10:13:56 +02:00
store_failed= store_failed ||
table->field[MYSQL_PROC_FIELD_DB_COLLATION]->store(
db_cs->name, strlen(db_cs->name), system_charset_info);
Patch for the following bugs: - BUG#11986: Stored routines and triggers can fail if the code has a non-ascii symbol - BUG#16291: mysqldump corrupts string-constants with non-ascii-chars - BUG#19443: INFORMATION_SCHEMA does not support charsets properly - BUG#21249: Character set of SP-var can be ignored - BUG#25212: Character set of string constant is ignored (stored routines) - BUG#25221: Character set of string constant is ignored (triggers) There were a few general problems that caused these bugs: 1. Character set information of the original (definition) query for views, triggers, stored routines and events was lost. 2. mysqldump output query in client character set, which can be inappropriate to encode definition-query. 3. INFORMATION_SCHEMA used strings with mixed encodings to display object definition; 1. No query-definition-character set. In order to compile query into execution code, some extra data (such as environment variables or the database character set) is used. The problem here was that this context was not preserved. So, on the next load it can differ from the original one, thus the result will be different. The context contains the following data: - client character set; - connection collation (character set and collation); - collation of the owner database; The fix is to store this context and use it each time we parse (compile) and execute the object (stored routine, trigger, ...). 2. Wrong mysqldump-output. The original query can contain several encodings (by means of character set introducers). The problem here was that we tried to convert original query to the mysqldump-client character set. Moreover, we stored queries in different character sets for different objects (views, for one, used UTF8, triggers used original character set). The solution is - to store definition queries in the original character set; - to change SHOW CREATE statement to output definition query in the binary character set (i.e. without any conversion); - introduce SHOW CREATE TRIGGER statement; - to dump special statements to switch the context to the original one before dumping and restore it afterwards. Note, in order to preserve the database collation at the creation time, additional ALTER DATABASE might be used (to temporary switch the database collation back to the original value). In this case, ALTER DATABASE privilege will be required. This is a backward-incompatible change. 3. INFORMATION_SCHEMA showed non-UTF8 strings The fix is to generate UTF8-query during the parsing, store it in the object and show it in the INFORMATION_SCHEMA. Basically, the idea is to create a copy of the original query convert it to UTF8. Character set introducers are removed and all text literals are converted to UTF8. This UTF8 query is intended to provide user-readable output. It must not be used to recreate the object. Specialized SHOW CREATE statements should be used for this. The reason for this limitation is the following: the original query can contain symbols from several character sets (by means of character set introducers). Example: - original query: CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1; - UTF8 query (for INFORMATION_SCHEMA): CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 19:34:54 +02:00
table->field[MYSQL_PROC_FIELD_BODY_UTF8]->set_notnull();
Fix for BUG#24923: Functions with ENUM issues. The problem was that the RETURNS column in the mysql.proc was of CHAR(64). That was not enough for storing long-named datatypes. The fix is to change CHAR(64) to LONGBLOB, and to throw warnings at the time a stored routine is created if some data is truncated during writing into mysql.proc.
2007-10-17 10:13:56 +02:00
store_failed= store_failed ||
table->field[MYSQL_PROC_FIELD_BODY_UTF8]->store(
sp->m_body_utf8.str, sp->m_body_utf8.length, system_charset_info);
if (store_failed)
{
ret= SP_FLD_STORE_FAILED;
goto done;
}
Patch for the following bugs: - BUG#11986: Stored routines and triggers can fail if the code has a non-ascii symbol - BUG#16291: mysqldump corrupts string-constants with non-ascii-chars - BUG#19443: INFORMATION_SCHEMA does not support charsets properly - BUG#21249: Character set of SP-var can be ignored - BUG#25212: Character set of string constant is ignored (stored routines) - BUG#25221: Character set of string constant is ignored (triggers) There were a few general problems that caused these bugs: 1. Character set information of the original (definition) query for views, triggers, stored routines and events was lost. 2. mysqldump output query in client character set, which can be inappropriate to encode definition-query. 3. INFORMATION_SCHEMA used strings with mixed encodings to display object definition; 1. No query-definition-character set. In order to compile query into execution code, some extra data (such as environment variables or the database character set) is used. The problem here was that this context was not preserved. So, on the next load it can differ from the original one, thus the result will be different. The context contains the following data: - client character set; - connection collation (character set and collation); - collation of the owner database; The fix is to store this context and use it each time we parse (compile) and execute the object (stored routine, trigger, ...). 2. Wrong mysqldump-output. The original query can contain several encodings (by means of character set introducers). The problem here was that we tried to convert original query to the mysqldump-client character set. Moreover, we stored queries in different character sets for different objects (views, for one, used UTF8, triggers used original character set). The solution is - to store definition queries in the original character set; - to change SHOW CREATE statement to output definition query in the binary character set (i.e. without any conversion); - introduce SHOW CREATE TRIGGER statement; - to dump special statements to switch the context to the original one before dumping and restore it afterwards. Note, in order to preserve the database collation at the creation time, additional ALTER DATABASE might be used (to temporary switch the database collation back to the original value). In this case, ALTER DATABASE privilege will be required. This is a backward-incompatible change. 3. INFORMATION_SCHEMA showed non-UTF8 strings The fix is to generate UTF8-query during the parsing, store it in the object and show it in the INFORMATION_SCHEMA. Basically, the idea is to create a copy of the original query convert it to UTF8. Character set introducers are removed and all text literals are converted to UTF8. This UTF8 query is intended to provide user-readable output. It must not be used to recreate the object. Specialized SHOW CREATE statements should be used for this. The reason for this limitation is the following: the original query can contain symbols from several character sets (by means of character set introducers). Example: - original query: CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1; - UTF8 query (for INFORMATION_SCHEMA): CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 19:34:54 +02:00
Fixed memory leaks in SP Some code cleanup
2003-12-21 11:48:03 +01:00
ret= SP_OK;
WL#1012: All changes as one single changeset. This includes both code and test cases.
2005-12-22 06:39:02 +01:00
if (table->file->ha_write_row(table->record[0]))
Most of the groundwork for sprint task 729 (implement FUNCTIONs). Expanded the mysql.proc table, reworked the find/create/drop functions completely, added new functions for FUNCTIONs (lotta functions here :), got rid of some unnecessary use of Item_strings while at it. Extended the parser correspondingly, and fiddled around a bit to make SP FUNCTIONs coexist with UDFs. Can now CREATE and DROP FUNCTIONs. Invoking yet to come...
2003-02-21 17:37:05 +01:00
ret= SP_WRITE_ROW_FAILED;
Approximative fixes for BUG#2610,2611,9100 i.e. WL#2146 binlogging/replication of routines (stored procs and functions). Approximative, because it's using our binlogging way (what we call "query"-level) and this is not as good as record-level binlog (5.1) would be. It imposes several limitations to routines, and has caveats (which I'll document, and for which the server will try to issue errors but that is not always possible). Reason I don't propagate caller info to the binlog as planned is that on master and slave users may be different; even with that some caveats would remain.
2005-05-05 14:20:53 +02:00
else if (mysql_bin_log.is_open())
{
thd->clear_error();
Implementation of WL#2897: Complete definer support in the stored routines. The idea is to add DEFINER-clause in CREATE PROCEDURE and CREATE FUNCTION statements. Almost all support of definer in stored routines had been already done before this patch. NOTE: this patch changes behaviour of dumping stored routines in mysqldump. Before this patch, mysqldump did not dump DEFINER-clause for stored routines and this was documented behaviour. In order to get full information about stored routines, one should have dumped mysql.proc table. This patch changes this behaviour, so that DEFINER-clause is dumped. Since DEFINER-clause is not supported in CREATE PROCEDURE | FUNCTION statements before this patch, the clause is covered by additional version-specific comments.
2006-03-02 13:18:49 +01:00
String log_query;
log_query.set_charset(system_charset_info);
Bug#25411 (trigger code truncated), PART II Bug 28127 (Some valid identifiers names are not parsed correctly) Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func) This patch is the second part of a major cleanup, required to fix Bug 25411 (trigger code truncated). The root cause of the issue stems from the function skip_rear_comments, which was a work around to remove "extra" "*/" characters from the query text, when parsing a query and reusing the text fragments to represent a view, trigger, function or stored procedure. The reason for this work around is that "special comments", like /*!50002 XXX */, were not parsed properly, so that a query like: AAA /*!50002 BBB */ CCC would be seen by the parser as "AAA BBB */ CCC" when the current version is greater or equal to 5.0.2 The root cause of this stems from how special comments are parsed. Special comments are really out-of-bound text that appear inside a query, that affects how the parser behave. In nature, /*!50002 XXX */ in MySQL is similar to the C concept of preprocessing : #if VERSION >= 50002 XXX #endif Depending on the current VERSION of the server, either the special comment should be expanded or it should be ignored, but in all cases the "text" of the query should be re-written to strip the "/*!50002" and "*/" markers, which does not belong to the SQL language itself. Prior to this fix, these markers would leak into : - the storage format for VIEW, - the storage format for FUNCTION, - the storage format for FUNCTION parameters, in mysql.proc (param_list), - the storage format for PROCEDURE, - the storage format for PROCEDURE parameters, in mysql.proc (param_list), - the storage format for TRIGGER, - the binary log used for replication. In all cases, not only this cause format corruption, but also provide a vector for dormant security issues, by allowing to tunnel code that will be activated after an upgrade. The proper solution is to deal with special comments strictly during parsing, when accepting a query from the outside world. Once a query is parsed and an object is created with a persistant representation, this object should not arbitrarily mutate after an upgrade. In short, special comments are a useful but limited feature for MYSQLdump, when used at an *interface* level to facilitate import/export, but bloating the server *internal* storage format is *not* the proper way to deal with configuration management of the user logic. With this fix: - the Lex_input_stream class now acts as a comment pre-processor, and either expands or ignore special comments on the fly. - MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the public interface of Lex_input_stream. In particular, how the input stream accepts or rejects a character is private to Lex_input_stream, and the internal buffer pointers of that class are strictly private, and should not be tempered with during parsing. This caused many changes mostly in sql_lex.cc. During the code cleanup in case MY_LEX_NUMBER_IDENT, Bug 28127 (Some valid identifiers names are not parsed correctly) was found and fixed. By parsing special comments properly, and removing the function 'skip_rear_comments' [sic], Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func) has been fixed as well.
2007-06-12 23:23:58 +02:00
Bug#36570: Parse error of CREATE PROCEDURE stmt with comments on \ slave The stored-routine code took the contents of the (lowest) parser and copied it directly to the binlog, which causes problems if there is a special case of interpretation at the parser level -- which there is, in the "/*!VER */" comments. The trailing "*/" caused errors on the slave, naturally. Now, since by that point we have /properly/ created parse-tree (as the rest of the server should do!) for the stored-routine CREATE, we can construct a perfect statement from that information, instead of writing uncertain information from an unknown parser state. Fortunately, there's already a function nearby that does exactly that.
2008-05-15 01:23:54 +02:00
if (!create_string(thd, &log_query,
sp->m_type,
Bug#36570: Parse error of CREATE PROCEDURE stmt with comments on \ slave The stored-routine code took the contents of the (lowest) parser and copied it directly to the binlog, which causes problems if there is a special case of interpretation at the parser level -- which there is, in the "/*!VER */" comments. The trailing "*/" caused errors on the slave, naturally. Now, since by that point we have /properly/ created parse-tree (as the rest of the server should do!) for the stored-routine CREATE, we can construct a perfect statement from that information, instead of writing uncertain information from an unknown parser state. Fortunately, there's already a function nearby that does exactly that. --- Update for Bug#36570. Qualify routine names with db name when writing to the binlog ONLY if the source text is qualified.
2008-05-16 01:13:24 +02:00
(sp->m_explicit_name ? sp->m_db.str : NULL),
(sp->m_explicit_name ? sp->m_db.length : 0),
Bug#36570: Parse error of CREATE PROCEDURE stmt with comments on \ slave The stored-routine code took the contents of the (lowest) parser and copied it directly to the binlog, which causes problems if there is a special case of interpretation at the parser level -- which there is, in the "/*!VER */" comments. The trailing "*/" caused errors on the slave, naturally. Now, since by that point we have /properly/ created parse-tree (as the rest of the server should do!) for the stored-routine CREATE, we can construct a perfect statement from that information, instead of writing uncertain information from an unknown parser state. Fortunately, there's already a function nearby that does exactly that.
2008-05-15 01:23:54 +02:00
sp->m_name.str, sp->m_name.length,
sp->m_params.str, sp->m_params.length,
retstr.c_ptr(), retstr.length(),
sp->m_body.str, sp->m_body.length,
sp->m_chistics, &(thd->lex->definer->user),
&(thd->lex->definer->host)))
{
ret= SP_INTERNAL_ERROR;
goto done;
}
BUG#39526 sql_mode not retained in binary log for CREATE PROCEDURE Set wrong sql_mode when creating a procedure. So that the sql_mode can't be writen into binary log correctly. Restore the current session sql_mode right before generating the binlog event when creating a procedure.
2009-02-28 02:35:18 +01:00
/* restore sql_mode when binloging */
thd->variables.sql_mode= saved_mode;
Approximative fixes for BUG#2610,2611,9100 i.e. WL#2146 binlogging/replication of routines (stored procs and functions). Approximative, because it's using our binlogging way (what we call "query"-level) and this is not as good as record-level binlog (5.1) would be. It imposes several limitations to routines, and has caveats (which I'll document, and for which the server will try to issue errors but that is not always possible). Reason I don't propagate caller info to the binlog as planned is that on master and slave users may be different; even with that some caveats would remain.
2005-05-05 14:20:53 +02:00
/* Such a statement can always go directly to binlog, no trans cache */
WL#1012: All changes as one single changeset. This includes both code and test cases.
2005-12-22 06:39:02 +01:00
thd->binlog_query(THD::MYSQL_QUERY_TYPE,
Manually merge BUG#37145 to 5.1-bugteam
2009-04-09 01:42:51 +02:00
log_query.c_ptr(), log_query.length(),
FALSE, FALSE, THD::NOT_KILLED);
BUG#39526 sql_mode not retained in binary log for CREATE PROCEDURE Set wrong sql_mode when creating a procedure. So that the sql_mode can't be writen into binary log correctly. Restore the current session sql_mode right before generating the binlog event when creating a procedure.
2009-02-28 02:35:18 +01:00
thd->variables.sql_mode= 0;
Approximative fixes for BUG#2610,2611,9100 i.e. WL#2146 binlogging/replication of routines (stored procs and functions). Approximative, because it's using our binlogging way (what we call "query"-level) and this is not as good as record-level binlog (5.1) would be. It imposes several limitations to routines, and has caveats (which I'll document, and for which the server will try to issue errors but that is not always possible). Reason I don't propagate caller info to the binlog as planned is that on master and slave users may be different; even with that some caveats would remain.
2005-05-05 14:20:53 +02:00
}
Moved create/find/drop functions to a separate files (sp.cc,sp.h). Fixed backpatching of forward jumps. Implemented LOOP, WHILE, REPEAT (temporarily known as SPREPEAT). Known bug: Expression evaluation still not quite ok (e.g. "x > 0"), which is why IF and CASE is not yet implemented.
2002-12-12 13:14:23 +01:00
}
Added more error handling for abnormal cases (like a broken mysql.proc table).
2003-10-30 10:25:45 +01:00
done:
Fix for BUG#24923: Functions with ENUM issues. The problem was that the RETURNS column in the mysql.proc was of CHAR(64). That was not enough for storing long-named datatypes. The fix is to change CHAR(64) to LONGBLOB, and to throw warnings at the time a stored routine is created if some data is truncated during writing into mysql.proc.
2007-10-17 10:13:56 +02:00
thd->count_cuted_fields= saved_count_cuted_fields;
Bug#32633 Can not create any routine if SQL_MODE=no_engine_substitution The problem is that one can not create a stored routine if sql_mode contains NO_ENGINE_SUBSTITUTION or PAD_CHAR_TO_FULL_LENGTH. Also when a event is created, the mode is silently lost if sql_mode contains one of the aforementioned. This was happening because the table definitions which stored sql_mode values weren't being updated to accept new values of sql_mode. The solution is to update, in a backwards compatible manner, the various table definitions (columns) that store the sql_mode value to take into account the new possible values. One incompatible change is that if a event that is being created can't be stored to the mysql.event table, an error will be raised. The tests case also ensure that new SQL modes will be added to the mysql.proc and mysql.event tables, otherwise the tests will fail.
2008-02-07 11:47:39 +01:00
thd->variables.sql_mode= saved_mode;
Fix for BUG#24923: Functions with ENUM issues. The problem was that the RETURNS column in the mysql.proc was of CHAR(64). That was not enough for storing long-named datatypes. The fix is to change CHAR(64) to LONGBLOB, and to throw warnings at the time a stored routine is created if some data is truncated during writing into mysql.proc.
2007-10-17 10:13:56 +02:00
Closing tables during SP execution the proper way.
2003-02-28 15:07:14 +01:00
close_thread_tables(thd);
Most of the groundwork for sprint task 729 (implement FUNCTIONs). Expanded the mysql.proc table, reworked the find/create/drop functions completely, added new functions for FUNCTIONs (lotta functions here :), got rid of some unnecessary use of Item_strings while at it. Extended the parser correspondingly, and fiddled around a bit to make SP FUNCTIONs coexist with UDFs. Can now CREATE and DROP FUNCTIONs. Invoking yet to come...
2003-02-21 17:37:05 +01:00
DBUG_RETURN(ret);
}
Moved create/find/drop functions to a separate files (sp.cc,sp.h). Fixed backpatching of forward jumps. Implemented LOOP, WHILE, REPEAT (temporarily known as SPREPEAT). Known bug: Expression evaluation still not quite ok (e.g. "x > 0"), which is why IF and CASE is not yet implemented.
2002-12-12 13:14:23 +01:00
Fixed memory leaks in SP Some code cleanup
2003-12-21 11:48:03 +01:00
Refactoring patch: 1. Refactor sp_show_create_function() and sp_show_create_procedure() into show_create_routine(). 2. Code cleanup: eliminate proxy functions.
2007-05-29 19:22:33 +02:00
/**
Delete the record for the stored routine object from mysql.proc.
The operation deletes the record for the stored routine specified by name
from the mysql.proc table and invalidates the stored-routine cache.
@param thd Thread context.
@param type Stored routine type
(TYPE_ENUM_PROCEDURE or TYPE_ENUM_FUNCTION)
@param name Stored routine name.
@return Error code. SP_OK is returned on success. Other SP_ constants are
used to indicate about errors.
*/
int
sp_drop_routine(THD *thd, int type, sp_name *name)
Most of the groundwork for sprint task 729 (implement FUNCTIONs). Expanded the mysql.proc table, reworked the find/create/drop functions completely, added new functions for FUNCTIONs (lotta functions here :), got rid of some unnecessary use of Item_strings while at it. Extended the parser correspondingly, and fiddled around a bit to make SP FUNCTIONs coexist with UDFs. Can now CREATE and DROP FUNCTIONs. Invoking yet to come...
2003-02-21 17:37:05 +01:00
{
TABLE *table;
int ret;
Refactoring patch: 1. Refactor sp_show_create_function() and sp_show_create_procedure() into show_create_routine(). 2. Code cleanup: eliminate proxy functions.
2007-05-29 19:22:33 +02:00
DBUG_ENTER("sp_drop_routine");
WL#3817: Simplify string / memory area types and make things more consistent (first part) The following type conversions was done: - Changed byte to uchar - Changed gptr to uchar* - Change my_string to char * - Change my_size_t to size_t - Change size_s to size_t Removed declaration of byte, gptr, my_string, my_size_t and size_s. Following function parameter changes was done: - All string functions in mysys/strings was changed to use size_t instead of uint for string lengths. - All read()/write() functions changed to use size_t (including vio). - All protocoll functions changed to use size_t instead of uint - Functions that used a pointer to a string length was changed to use size_t* - Changed malloc(), free() and related functions from using gptr to use void * as this requires fewer casts in the code and is more in line with how the standard functions work. - Added extra length argument to dirname_part() to return the length of the created string. - Changed (at least) following functions to take uchar* as argument: - db_dump() - my_net_write() - net_write_command() - net_store_data() - DBUG_DUMP() - decimal2bin() & bin2decimal() - Changed my_compress() and my_uncompress() to use size_t. Changed one argument to my_uncompress() from a pointer to a value as we only return one value (makes function easier to use). - Changed type of 'pack_data' argument to packfrm() to avoid casts. - Changed in readfrm() and writefrom(), ha_discover and handler::discover() the type for argument 'frmdata' to uchar** to avoid casts. - Changed most Field functions to use uchar* instead of char* (reduced a lot of casts). - Changed field->val_xxx(xxx, new_ptr) to take const pointers. Other changes: - Removed a lot of not needed casts - Added a few new cast required by other changes - Added some cast to my_multi_malloc() arguments for safety (as string lengths needs to be uint, not size_t). - Fixed all calls to hash-get-key functions to use size_t*. (Needed to be done explicitely as this conflict was often hided by casting the function to hash_get_key). - Changed some buffers to memory regions to uchar* to avoid casts. - Changed some string lengths from uint to size_t. - Changed field->ptr to be uchar* instead of char*. This allowed us to get rid of a lot of casts. - Some changes from true -> TRUE, false -> FALSE, unsigned char -> uchar - Include zlib.h in some files as we needed declaration of crc32() - Changed MY_FILE_ERROR to be (size_t) -1. - Changed many variables to hold the result of my_read() / my_write() to be size_t. This was needed to properly detect errors (which are returned as (size_t) -1). - Removed some very old VMS code - Changed packfrm()/unpackfrm() to not be depending on uint size (portability fix) - Removed windows specific code to restore cursor position as this causes slowdown on windows and we should not mix read() and pread() calls anyway as this is not thread safe. Updated function comment to reflect this. Changed function that depended on original behavior of my_pwrite() to itself restore the cursor position (one such case). - Added some missing checking of return value of malloc(). - Changed definition of MOD_PAD_CHAR_TO_FULL_LENGTH to avoid 'long' overflow. - Changed type of table_def::m_size from my_size_t to ulong to reflect that m_size is the number of elements in the array, not a string/memory length. - Moved THD::max_row_length() to table.cc (as it's not depending on THD). Inlined max_row_length_blob() into this function. - More function comments - Fixed some compiler warnings when compiled without partitions. - Removed setting of LEX_STRING() arguments in declaration (portability fix). - Some trivial indentation/variable name changes. - Some trivial code simplifications: - Replaced some calls to alloc_root + memcpy to use strmake_root()/strdup_root(). - Changed some calls from memdup() to strmake() (Safety fix) - Simpler loops in client-simple.c
2007-05-10 11:59:39 +02:00
DBUG_PRINT("enter", ("type: %d name: %.*s",
type, (int) name->m_name.length, name->m_name.str));
Moved create/find/drop functions to a separate files (sp.cc,sp.h). Fixed backpatching of forward jumps. Implemented LOOP, WHILE, REPEAT (temporarily known as SPREPEAT). Known bug: Expression evaluation still not quite ok (e.g. "x > 0"), which is why IF and CASE is not yet implemented.
2002-12-12 13:14:23 +01:00
Refactoring patch: 1. Refactor sp_show_create_function() and sp_show_create_procedure() into show_create_routine(). 2. Code cleanup: eliminate proxy functions.
2007-05-29 19:22:33 +02:00
DBUG_ASSERT(type == TYPE_ENUM_PROCEDURE ||
type == TYPE_ENUM_FUNCTION);
BUG#25091 (A DELETE statement to mysql database is not logged in ROW format): With this patch, statements that change metadata (in the mysql database) is logged as statements, while normal changes (e.g., using INSERT, DELETE, and/or UPDATE) is logged according to the format in effect. The log tables (i.e., general_log and slow_log) are not replicated at all. With this patch, the following statements are replicated as statements: GRANT, REVOKE (ALL), CREATE USER, DROP USER, and RENAME USER.
2007-02-26 10:19:08 +01:00
/*
This statement will be replicated as a statement, even when using
row-based replication. The flag will be reset at the end of the
statement.
*/
thd->clear_current_stmt_binlog_row_based();
Implementation of Monty's idea: Now we can open mysql.proc table for lookup of stored routines definitions even if we already have some tables open and locked. To avoid deadlocks in this case we have to put certain restrictions on locking of mysql.proc table. This allows to use stored routines safely under LOCK TABLES without explicitly mentioning mysql.proc in the list of locked tables. It also fixes bug #11554 "Server crashes on statement indirectly using non-cached function".
2005-07-13 11:48:13 +02:00
if (!(table= open_proc_table_for_update(thd)))
DBUG_RETURN(SP_OPEN_TABLE_FAILED);
if ((ret= db_find_routine_aux(thd, type, name, table)) == SP_OK)
Most of the groundwork for sprint task 729 (implement FUNCTIONs). Expanded the mysql.proc table, reworked the find/create/drop functions completely, added new functions for FUNCTIONs (lotta functions here :), got rid of some unnecessary use of Item_strings while at it. Extended the parser correspondingly, and fiddled around a bit to make SP FUNCTIONs coexist with UDFs. Can now CREATE and DROP FUNCTIONs. Invoking yet to come...
2003-02-21 17:37:05 +01:00
{
WL#1012: All changes as one single changeset. This includes both code and test cases.
2005-12-22 06:39:02 +01:00
if (table->file->ha_delete_row(table->record[0]))
Most of the groundwork for sprint task 729 (implement FUNCTIONs). Expanded the mysql.proc table, reworked the find/create/drop functions completely, added new functions for FUNCTIONs (lotta functions here :), got rid of some unnecessary use of Item_strings while at it. Extended the parser correspondingly, and fiddled around a bit to make SP FUNCTIONs coexist with UDFs. Can now CREATE and DROP FUNCTIONs. Invoking yet to come...
2003-02-21 17:37:05 +01:00
ret= SP_DELETE_ROW_FAILED;
}
Bug #14262: SP: DROP PROCEDURE|VIEW (maybe more) write to binlog too late \ (race cond) It was possible for one thread to interrupt a Data Definition Language statement and thereby get messages to the binlog out of order. Consider: Connection 1: Drop Foo x Connection 2: Create or replace Foo x Connection 2: Log "Create or replace Foo x" Connection 1: Log "Drop Foo x" Local end would have Foo x, but the replicated slaves would not. The fix for this is to wrap all DDL and logging of a kind in the same mutex. Since we already use mutexes for the various parts of altering the server, this only entails moving the logging events down close to the action, inside the mutex protection.
2006-10-03 19:38:25 +02:00
if (ret == SP_OK)
{
Bug #26418: Slave out of sync after CREATE/DROP TEMPORARY TABLE + ROLLBACK on master The transaction ability of the storage engines of the tables on the replication master and the replication slave must generally be the same. When the storage engine type of the slave is non-transactional then transactions on the master that mix update of transactional and non-transactional tables should be avoided because they will cause inconsistency of the data between the master's transactional table and the slave's non-transactional table. The effect described by this bug is actually expected. A detailed test case is added (to be merged later to the updated rpl_ddl.test), as there was no coverage by the existing tests. Some code cleanup is also added by this change.
2007-06-19 13:27:53 +02:00
write_bin_log(thd, TRUE, thd->query, thd->query_length);
Refactoring patch: 1. Refactor sp_show_create_function() and sp_show_create_procedure() into show_create_routine(). 2. Code cleanup: eliminate proxy functions.
2007-05-29 19:22:33 +02:00
sp_cache_invalidate();
Bug #14262: SP: DROP PROCEDURE|VIEW (maybe more) write to binlog too late \ (race cond) It was possible for one thread to interrupt a Data Definition Language statement and thereby get messages to the binlog out of order. Consider: Connection 1: Drop Foo x Connection 2: Create or replace Foo x Connection 2: Log "Create or replace Foo x" Connection 1: Log "Drop Foo x" Local end would have Foo x, but the replicated slaves would not. The fix for this is to wrap all DDL and logging of a kind in the same mutex. Since we already use mutexes for the various parts of altering the server, this only entails moving the logging events down close to the action, inside the mutex protection.
2006-10-03 19:38:25 +02:00
}
Implementation of Monty's idea: Now we can open mysql.proc table for lookup of stored routines definitions even if we already have some tables open and locked. To avoid deadlocks in this case we have to put certain restrictions on locking of mysql.proc table. This allows to use stored routines safely under LOCK TABLES without explicitly mentioning mysql.proc in the list of locked tables. It also fixes bug #11554 "Server crashes on statement indirectly using non-cached function".
2005-07-13 11:48:13 +02:00
close_thread_tables(thd);
Most of the groundwork for sprint task 729 (implement FUNCTIONs). Expanded the mysql.proc table, reworked the find/create/drop functions completely, added new functions for FUNCTIONs (lotta functions here :), got rid of some unnecessary use of Item_strings while at it. Extended the parser correspondingly, and fiddled around a bit to make SP FUNCTIONs coexist with UDFs. Can now CREATE and DROP FUNCTIONs. Invoking yet to come...
2003-02-21 17:37:05 +01:00
DBUG_RETURN(ret);
}
Fixed memory leaks in SP Some code cleanup
2003-12-21 11:48:03 +01:00
Refactoring patch: 1. Refactor sp_show_create_function() and sp_show_create_procedure() into show_create_routine(). 2. Code cleanup: eliminate proxy functions.
2007-05-29 19:22:33 +02:00
/**
Find and updated the record for the stored routine object in mysql.proc.
The operation finds the record for the stored routine specified by name
in the mysql.proc table and updates it with new attributes. After
successful update, the cache is invalidated.
@param thd Thread context.
@param type Stored routine type
(TYPE_ENUM_PROCEDURE or TYPE_ENUM_FUNCTION)
@param name Stored routine name.
@param chistics New values of stored routine attributes to write.
@return Error code. SP_OK is returned on success. Other SP_ constants are
used to indicate about errors.
*/
int
sp_update_routine(THD *thd, int type, sp_name *name, st_sp_chistics *chistics)
WL#1241: SHOW PROCEDURE/FUNCTION WL#1263: Support for the attributes COMMENT and SUID in CREATE/ALTER PROCEDURE/FUNCTION
2003-11-17 18:21:36 +01:00
{
TABLE *table;
int ret;
Refactoring patch: 1. Refactor sp_show_create_function() and sp_show_create_procedure() into show_create_routine(). 2. Code cleanup: eliminate proxy functions.
2007-05-29 19:22:33 +02:00
DBUG_ENTER("sp_update_routine");
WL#3817: Simplify string / memory area types and make things more consistent (first part) The following type conversions was done: - Changed byte to uchar - Changed gptr to uchar* - Change my_string to char * - Change my_size_t to size_t - Change size_s to size_t Removed declaration of byte, gptr, my_string, my_size_t and size_s. Following function parameter changes was done: - All string functions in mysys/strings was changed to use size_t instead of uint for string lengths. - All read()/write() functions changed to use size_t (including vio). - All protocoll functions changed to use size_t instead of uint - Functions that used a pointer to a string length was changed to use size_t* - Changed malloc(), free() and related functions from using gptr to use void * as this requires fewer casts in the code and is more in line with how the standard functions work. - Added extra length argument to dirname_part() to return the length of the created string. - Changed (at least) following functions to take uchar* as argument: - db_dump() - my_net_write() - net_write_command() - net_store_data() - DBUG_DUMP() - decimal2bin() & bin2decimal() - Changed my_compress() and my_uncompress() to use size_t. Changed one argument to my_uncompress() from a pointer to a value as we only return one value (makes function easier to use). - Changed type of 'pack_data' argument to packfrm() to avoid casts. - Changed in readfrm() and writefrom(), ha_discover and handler::discover() the type for argument 'frmdata' to uchar** to avoid casts. - Changed most Field functions to use uchar* instead of char* (reduced a lot of casts). - Changed field->val_xxx(xxx, new_ptr) to take const pointers. Other changes: - Removed a lot of not needed casts - Added a few new cast required by other changes - Added some cast to my_multi_malloc() arguments for safety (as string lengths needs to be uint, not size_t). - Fixed all calls to hash-get-key functions to use size_t*. (Needed to be done explicitely as this conflict was often hided by casting the function to hash_get_key). - Changed some buffers to memory regions to uchar* to avoid casts. - Changed some string lengths from uint to size_t. - Changed field->ptr to be uchar* instead of char*. This allowed us to get rid of a lot of casts. - Some changes from true -> TRUE, false -> FALSE, unsigned char -> uchar - Include zlib.h in some files as we needed declaration of crc32() - Changed MY_FILE_ERROR to be (size_t) -1. - Changed many variables to hold the result of my_read() / my_write() to be size_t. This was needed to properly detect errors (which are returned as (size_t) -1). - Removed some very old VMS code - Changed packfrm()/unpackfrm() to not be depending on uint size (portability fix) - Removed windows specific code to restore cursor position as this causes slowdown on windows and we should not mix read() and pread() calls anyway as this is not thread safe. Updated function comment to reflect this. Changed function that depended on original behavior of my_pwrite() to itself restore the cursor position (one such case). - Added some missing checking of return value of malloc(). - Changed definition of MOD_PAD_CHAR_TO_FULL_LENGTH to avoid 'long' overflow. - Changed type of table_def::m_size from my_size_t to ulong to reflect that m_size is the number of elements in the array, not a string/memory length. - Moved THD::max_row_length() to table.cc (as it's not depending on THD). Inlined max_row_length_blob() into this function. - More function comments - Fixed some compiler warnings when compiled without partitions. - Removed setting of LEX_STRING() arguments in declaration (portability fix). - Some trivial indentation/variable name changes. - Some trivial code simplifications: - Replaced some calls to alloc_root + memcpy to use strmake_root()/strdup_root(). - Changed some calls from memdup() to strmake() (Safety fix) - Simpler loops in client-simple.c
2007-05-10 11:59:39 +02:00
DBUG_PRINT("enter", ("type: %d name: %.*s",
type, (int) name->m_name.length, name->m_name.str));
Refactoring patch: 1. Refactor sp_show_create_function() and sp_show_create_procedure() into show_create_routine(). 2. Code cleanup: eliminate proxy functions.
2007-05-29 19:22:33 +02:00
DBUG_ASSERT(type == TYPE_ENUM_PROCEDURE ||
type == TYPE_ENUM_FUNCTION);
BUG#25091 (A DELETE statement to mysql database is not logged in ROW format): With this patch, statements that change metadata (in the mysql database) is logged as statements, while normal changes (e.g., using INSERT, DELETE, and/or UPDATE) is logged according to the format in effect. The log tables (i.e., general_log and slow_log) are not replicated at all. With this patch, the following statements are replicated as statements: GRANT, REVOKE (ALL), CREATE USER, DROP USER, and RENAME USER.
2007-02-26 10:19:08 +01:00
/*
This statement will be replicated as a statement, even when using
Merge bk-internal.mysql.com:/home/bk/mysql-5.1 into bodhi.(none):/opt/local/work/mysql-5.1-runtime
2007-06-01 10:12:06 +02:00
row-based replication. The flag will be reset at the end of the
BUG#25091 (A DELETE statement to mysql database is not logged in ROW format): With this patch, statements that change metadata (in the mysql database) is logged as statements, while normal changes (e.g., using INSERT, DELETE, and/or UPDATE) is logged according to the format in effect. The log tables (i.e., general_log and slow_log) are not replicated at all. With this patch, the following statements are replicated as statements: GRANT, REVOKE (ALL), CREATE USER, DROP USER, and RENAME USER.
2007-02-26 10:19:08 +01:00
statement.
*/
thd->clear_current_stmt_binlog_row_based();
Implementation of Monty's idea: Now we can open mysql.proc table for lookup of stored routines definitions even if we already have some tables open and locked. To avoid deadlocks in this case we have to put certain restrictions on locking of mysql.proc table. This allows to use stored routines safely under LOCK TABLES without explicitly mentioning mysql.proc in the list of locked tables. It also fixes bug #11554 "Server crashes on statement indirectly using non-cached function".
2005-07-13 11:48:13 +02:00
if (!(table= open_proc_table_for_update(thd)))
DBUG_RETURN(SP_OPEN_TABLE_FAILED);
if ((ret= db_find_routine_aux(thd, type, name, table)) == SP_OK)
WL#1241: SHOW PROCEDURE/FUNCTION WL#1263: Support for the attributes COMMENT and SUID in CREATE/ALTER PROCEDURE/FUNCTION
2003-11-17 18:21:36 +01:00
{
store_record(table,record[1]);
Fixes after merge with 4.1 FOUND is not a reserved keyword anymore Added Item_field::set_no_const_sub() to be able to mark fields that can't be substituted Added 'simple_select' method to be able to quickly determinate if a select_result is a normal SELECT Note that the 5.0 tree is not yet up to date: Sanja will have to fix multi-update-locks for this merge to be complete
2004-11-03 11:39:38 +01:00
table->timestamp_field_type= TIMESTAMP_NO_AUTO_SET;
WL#1241: SHOW PROCEDURE/FUNCTION WL#1263: Support for the attributes COMMENT and SUID in CREATE/ALTER PROCEDURE/FUNCTION
2003-11-17 18:21:36 +01:00
((Field_timestamp *)table->field[MYSQL_PROC_FIELD_MODIFIED])->set_time();
Implemented the stored procedure data access characteristics: NO SQL CONTAINS SQL (default) READS SQL DATA MODIFIES SQL DATA These are needed as hints for the replication. (Before this, we did have the default in the mysql.proc table, but no support in the parser.)
2004-10-14 18:07:09 +02:00
if (chistics->suid != SP_IS_DEFAULT_SUID)
table->field[MYSQL_PROC_FIELD_SECURITY_TYPE]->
String::set(double) and set(longlong) -> set_real() and set_int() fix Field::store(double) being used instead of store(longlong) NB: overloading functions is evil
2006-06-16 12:17:20 +02:00
store((longlong)chistics->suid, TRUE);
Implemented the stored procedure data access characteristics: NO SQL CONTAINS SQL (default) READS SQL DATA MODIFIES SQL DATA These are needed as hints for the replication. (Before this, we did have the default in the mysql.proc table, but no support in the parser.)
2004-10-14 18:07:09 +02:00
if (chistics->daccess != SP_DEFAULT_ACCESS)
table->field[MYSQL_PROC_FIELD_ACCESS]->
String::set(double) and set(longlong) -> set_real() and set_int() fix Field::store(double) being used instead of store(longlong) NB: overloading functions is evil
2006-06-16 12:17:20 +02:00
store((longlong)chistics->daccess, TRUE);
WL#1363: Update the mysql.proc table and add new fields. Also made the parsing and handling of SP characteristics more general and extendable, and added a few ch:istics.
2003-12-10 19:05:37 +01:00
if (chistics->comment.str)
table->field[MYSQL_PROC_FIELD_COMMENT]->store(chistics->comment.str,
chistics->comment.length,
WL#1241: SHOW PROCEDURE/FUNCTION WL#1263: Support for the attributes COMMENT and SUID in CREATE/ALTER PROCEDURE/FUNCTION
2003-11-17 18:21:36 +01:00
system_charset_info);
Bug #29157: UPDATE, changed rows incorrect Sometimes the number of really updated rows (with changed column values) cannot be determined at the server level alone (e.g. if the storage engine does not return enough column values to verify that). So the only dependable way in such cases is to let the storage engine return that information if possible. Fixed the bug at server level by providing a way for the storage engine to return information about wether it actually updated the row or the old and the new column values are the same. It can do that by returning HA_ERR_RECORD_IS_THE_SAME in ha_update_row(). Note that each storage engine may choose not to try to return this status code, so this behaviour remains storage engine specific.
2007-06-28 15:07:55 +02:00
if ((ret= table->file->ha_update_row(table->record[1],table->record[0])) &&
ret != HA_ERR_RECORD_IS_THE_SAME)
WL#1241: SHOW PROCEDURE/FUNCTION WL#1263: Support for the attributes COMMENT and SUID in CREATE/ALTER PROCEDURE/FUNCTION
2003-11-17 18:21:36 +01:00
ret= SP_WRITE_ROW_FAILED;
Bug #29157: UPDATE, changed rows incorrect Sometimes the number of really updated rows (with changed column values) cannot be determined at the server level alone (e.g. if the storage engine does not return enough column values to verify that). So the only dependable way in such cases is to let the storage engine return that information if possible. Fixed the bug at server level by providing a way for the storage engine to return information about wether it actually updated the row or the old and the new column values are the same. It can do that by returning HA_ERR_RECORD_IS_THE_SAME in ha_update_row(). Note that each storage engine may choose not to try to return this status code, so this behaviour remains storage engine specific.
2007-06-28 15:07:55 +02:00
else
ret= 0;
WL#1241: SHOW PROCEDURE/FUNCTION WL#1263: Support for the attributes COMMENT and SUID in CREATE/ALTER PROCEDURE/FUNCTION
2003-11-17 18:21:36 +01:00
}
Bug #14262: SP: DROP PROCEDURE|VIEW (maybe more) write to binlog too late \ (race cond) It was possible for one thread to interrupt a Data Definition Language statement and thereby get messages to the binlog out of order. Consider: Connection 1: Drop Foo x Connection 2: Create or replace Foo x Connection 2: Log "Create or replace Foo x" Connection 1: Log "Drop Foo x" Local end would have Foo x, but the replicated slaves would not. The fix for this is to wrap all DDL and logging of a kind in the same mutex. Since we already use mutexes for the various parts of altering the server, this only entails moving the logging events down close to the action, inside the mutex protection.
2006-10-03 19:38:25 +02:00
if (ret == SP_OK)
{
Bug #26418: Slave out of sync after CREATE/DROP TEMPORARY TABLE + ROLLBACK on master The transaction ability of the storage engines of the tables on the replication master and the replication slave must generally be the same. When the storage engine type of the slave is non-transactional then transactions on the master that mix update of transactional and non-transactional tables should be avoided because they will cause inconsistency of the data between the master's transactional table and the slave's non-transactional table. The effect described by this bug is actually expected. A detailed test case is added (to be merged later to the updated rpl_ddl.test), as there was no coverage by the existing tests. Some code cleanup is also added by this change.
2007-06-19 13:27:53 +02:00
write_bin_log(thd, TRUE, thd->query, thd->query_length);
Refactoring patch: 1. Refactor sp_show_create_function() and sp_show_create_procedure() into show_create_routine(). 2. Code cleanup: eliminate proxy functions.
2007-05-29 19:22:33 +02:00
sp_cache_invalidate();
Bug #14262: SP: DROP PROCEDURE|VIEW (maybe more) write to binlog too late \ (race cond) It was possible for one thread to interrupt a Data Definition Language statement and thereby get messages to the binlog out of order. Consider: Connection 1: Drop Foo x Connection 2: Create or replace Foo x Connection 2: Log "Create or replace Foo x" Connection 1: Log "Drop Foo x" Local end would have Foo x, but the replicated slaves would not. The fix for this is to wrap all DDL and logging of a kind in the same mutex. Since we already use mutexes for the various parts of altering the server, this only entails moving the logging events down close to the action, inside the mutex protection.
2006-10-03 19:38:25 +02:00
}
Implementation of Monty's idea: Now we can open mysql.proc table for lookup of stored routines definitions even if we already have some tables open and locked. To avoid deadlocks in this case we have to put certain restrictions on locking of mysql.proc table. This allows to use stored routines safely under LOCK TABLES without explicitly mentioning mysql.proc in the list of locked tables. It also fixes bug #11554 "Server crashes on statement indirectly using non-cached function".
2005-07-13 11:48:13 +02:00
close_thread_tables(thd);
WL#1241: SHOW PROCEDURE/FUNCTION WL#1263: Support for the attributes COMMENT and SUID in CREATE/ALTER PROCEDURE/FUNCTION
2003-11-17 18:21:36 +01:00
DBUG_RETURN(ret);
}
Fixed memory leaks in SP Some code cleanup
2003-12-21 11:48:03 +01:00
A fix and a test case for Bug#12713 "Error in a stored function called from a SELECT doesn't cause ROLLBACK of statem". The idea of the fix is to ensure that we always commit the current statement at the end of dispatch_command(). In order to not issue redundant disc syncs, an optimization of the two-phase commit protocol is implemented to bypass the two phase commit if the transaction is read-only.
2008-02-19 12:43:01 +01:00
/**
Drop all routines in database 'db'
@note Close the thread tables, the calling code might want to
delete from other system tables afterwards.
*/
WL#1366: Use the schema (db) associated with an SP. Phase 4 (final): Remove associated stored procedures when a database is dropped.
2004-03-22 14:44:41 +01:00
int
sp_drop_db_routines(THD *thd, char *db)
{
TABLE *table;
int ret;
Fixed BUG#18344: DROP DATABASE does not drop associated routines We must use the db key length in sp_drop_db_routines (and not the number of characters), or long db names will be truncated in the key.
2006-04-18 16:01:01 +02:00
uint key_len;
WL#1366: Use the schema (db) associated with an SP. Phase 4 (final): Remove associated stored procedures when a database is dropped.
2004-03-22 14:44:41 +01:00
DBUG_ENTER("sp_drop_db_routines");
DBUG_PRINT("enter", ("db: %s", db));
Implementation of Monty's idea: Now we can open mysql.proc table for lookup of stored routines definitions even if we already have some tables open and locked. To avoid deadlocks in this case we have to put certain restrictions on locking of mysql.proc table. This allows to use stored routines safely under LOCK TABLES without explicitly mentioning mysql.proc in the list of locked tables. It also fixes bug #11554 "Server crashes on statement indirectly using non-cached function".
2005-07-13 11:48:13 +02:00
ret= SP_OPEN_TABLE_FAILED;
if (!(table= open_proc_table_for_update(thd)))
goto err;
WL#1366: Use the schema (db) associated with an SP. Phase 4 (final): Remove associated stored procedures when a database is dropped.
2004-03-22 14:44:41 +01:00
Fixed BUG#18344: DROP DATABASE does not drop associated routines We must use the db key length in sp_drop_db_routines (and not the number of characters), or long db names will be truncated in the key.
2006-04-18 16:01:01 +02:00
table->field[MYSQL_PROC_FIELD_DB]->store(db, strlen(db), system_charset_info);
key_len= table->key_info->key_part[0].store_length;
WL#1366: Use the schema (db) associated with an SP. Phase 4 (final): Remove associated stored procedures when a database is dropped.
2004-03-22 14:44:41 +01:00
ret= SP_OK;
Patch for push of wl1354 Partitioning
2005-07-18 13:31:02 +02:00
table->file->ha_index_init(0, 1);
Fixed a lot of compiler warnings and errors detected by Forte C++ on Solaris Faster thr_alarm() Added 'Opened_files' status variable to track calls to my_open() Don't give warnings when running mysql_install_db Added option --source-install to mysql_install_db I had to do the following renames() as used polymorphism didn't work with Forte compiler on 64 bit systems index_read() -> index_read_map() index_read_idx() -> index_read_idx_map() index_read_last() -> index_read_last_map()
2007-08-13 15:11:25 +02:00
if (! table->file->index_read_map(table->record[0],
(uchar *)table->field[MYSQL_PROC_FIELD_DB]->ptr,
(key_part_map)1, HA_READ_KEY_EXACT))
WL#1366: Use the schema (db) associated with an SP. Phase 4 (final): Remove associated stored procedures when a database is dropped.
2004-03-22 14:44:41 +01:00
{
int nxtres;
bool deleted= FALSE;
Implementation of Monty's idea: Now we can open mysql.proc table for lookup of stored routines definitions even if we already have some tables open and locked. To avoid deadlocks in this case we have to put certain restrictions on locking of mysql.proc table. This allows to use stored routines safely under LOCK TABLES without explicitly mentioning mysql.proc in the list of locked tables. It also fixes bug #11554 "Server crashes on statement indirectly using non-cached function".
2005-07-13 11:48:13 +02:00
do
{
WL#1012: All changes as one single changeset. This includes both code and test cases.
2005-12-22 06:39:02 +01:00
if (! table->file->ha_delete_row(table->record[0]))
WL#1366: Use the schema (db) associated with an SP. Phase 4 (final): Remove associated stored procedures when a database is dropped.
2004-03-22 14:44:41 +01:00
deleted= TRUE; /* We deleted something */
else
{
ret= SP_DELETE_ROW_FAILED;
Fixed BUG#3259: Stored procedure names are case sensitive. Procedure names were unintentionally case-sensitive when read from the database (but case-insensitive when fetched from the cache). Note that the DB-part of qualified names is still case-sensitive (for consistency with other usage in mysql).
2004-03-23 12:04:40 +01:00
nxtres= 0;
WL#1366: Use the schema (db) associated with an SP. Phase 4 (final): Remove associated stored procedures when a database is dropped.
2004-03-22 14:44:41 +01:00
break;
}
} while (! (nxtres= table->file->index_next_same(table->record[0],
WL#3817: Simplify string / memory area types and make things more consistent (first part) The following type conversions was done: - Changed byte to uchar - Changed gptr to uchar* - Change my_string to char * - Change my_size_t to size_t - Change size_s to size_t Removed declaration of byte, gptr, my_string, my_size_t and size_s. Following function parameter changes was done: - All string functions in mysys/strings was changed to use size_t instead of uint for string lengths. - All read()/write() functions changed to use size_t (including vio). - All protocoll functions changed to use size_t instead of uint - Functions that used a pointer to a string length was changed to use size_t* - Changed malloc(), free() and related functions from using gptr to use void * as this requires fewer casts in the code and is more in line with how the standard functions work. - Added extra length argument to dirname_part() to return the length of the created string. - Changed (at least) following functions to take uchar* as argument: - db_dump() - my_net_write() - net_write_command() - net_store_data() - DBUG_DUMP() - decimal2bin() & bin2decimal() - Changed my_compress() and my_uncompress() to use size_t. Changed one argument to my_uncompress() from a pointer to a value as we only return one value (makes function easier to use). - Changed type of 'pack_data' argument to packfrm() to avoid casts. - Changed in readfrm() and writefrom(), ha_discover and handler::discover() the type for argument 'frmdata' to uchar** to avoid casts. - Changed most Field functions to use uchar* instead of char* (reduced a lot of casts). - Changed field->val_xxx(xxx, new_ptr) to take const pointers. Other changes: - Removed a lot of not needed casts - Added a few new cast required by other changes - Added some cast to my_multi_malloc() arguments for safety (as string lengths needs to be uint, not size_t). - Fixed all calls to hash-get-key functions to use size_t*. (Needed to be done explicitely as this conflict was often hided by casting the function to hash_get_key). - Changed some buffers to memory regions to uchar* to avoid casts. - Changed some string lengths from uint to size_t. - Changed field->ptr to be uchar* instead of char*. This allowed us to get rid of a lot of casts. - Some changes from true -> TRUE, false -> FALSE, unsigned char -> uchar - Include zlib.h in some files as we needed declaration of crc32() - Changed MY_FILE_ERROR to be (size_t) -1. - Changed many variables to hold the result of my_read() / my_write() to be size_t. This was needed to properly detect errors (which are returned as (size_t) -1). - Removed some very old VMS code - Changed packfrm()/unpackfrm() to not be depending on uint size (portability fix) - Removed windows specific code to restore cursor position as this causes slowdown on windows and we should not mix read() and pread() calls anyway as this is not thread safe. Updated function comment to reflect this. Changed function that depended on original behavior of my_pwrite() to itself restore the cursor position (one such case). - Added some missing checking of return value of malloc(). - Changed definition of MOD_PAD_CHAR_TO_FULL_LENGTH to avoid 'long' overflow. - Changed type of table_def::m_size from my_size_t to ulong to reflect that m_size is the number of elements in the array, not a string/memory length. - Moved THD::max_row_length() to table.cc (as it's not depending on THD). Inlined max_row_length_blob() into this function. - More function comments - Fixed some compiler warnings when compiled without partitions. - Removed setting of LEX_STRING() arguments in declaration (portability fix). - Some trivial indentation/variable name changes. - Some trivial code simplifications: - Replaced some calls to alloc_root + memcpy to use strmake_root()/strdup_root(). - Changed some calls from memdup() to strmake() (Safety fix) - Simpler loops in client-simple.c
2007-05-10 11:59:39 +02:00
(uchar *)table->field[MYSQL_PROC_FIELD_DB]->ptr,
Fixed BUG#18344: DROP DATABASE does not drop associated routines We must use the db key length in sp_drop_db_routines (and not the number of characters), or long db names will be truncated in the key.
2006-04-18 16:01:01 +02:00
key_len)));
WL#1366: Use the schema (db) associated with an SP. Phase 4 (final): Remove associated stored procedures when a database is dropped.
2004-03-22 14:44:41 +01:00
if (nxtres != HA_ERR_END_OF_FILE)
ret= SP_KEY_NOT_FOUND;
if (deleted)
sp_cache_invalidate();
}
After merge fixes Note: The following tests fails - fulltext (Sergei has promised to fix) - rpl_charset (Guilhem should fix) - rpl_timezone (Dimitray has promised to fix) Sanja needs to check out the calling of close_thread_tables() in sp_head.cc
2004-07-15 03:19:07 +02:00
table->file->ha_index_end();
WL#1366: Use the schema (db) associated with an SP. Phase 4 (final): Remove associated stored procedures when a database is dropped.
2004-03-22 14:44:41 +01:00
close_thread_tables(thd);
Implementation of Monty's idea: Now we can open mysql.proc table for lookup of stored routines definitions even if we already have some tables open and locked. To avoid deadlocks in this case we have to put certain restrictions on locking of mysql.proc table. This allows to use stored routines safely under LOCK TABLES without explicitly mentioning mysql.proc in the list of locked tables. It also fixes bug #11554 "Server crashes on statement indirectly using non-cached function".
2005-07-13 11:48:13 +02:00
err:
WL#1366: Use the schema (db) associated with an SP. Phase 4 (final): Remove associated stored procedures when a database is dropped.
2004-03-22 14:44:41 +01:00
DBUG_RETURN(ret);
}
Refactoring patch: 1. Refactor sp_show_create_function() and sp_show_create_procedure() into show_create_routine(). 2. Code cleanup: eliminate proxy functions.
2007-05-29 19:22:33 +02:00
/**
Implement SHOW CREATE statement for stored routines.
The operation finds the stored routine object specified by name and then
calls sp_head::show_create_routine() for the object.
@param thd Thread context.
@param type Stored routine type
(TYPE_ENUM_PROCEDURE or TYPE_ENUM_FUNCTION)
@param name Stored routine name.
@return Error status.
@retval FALSE on success
@retval TRUE on error
*/
bool
sp_show_create_routine(THD *thd, int type, sp_name *name)
{
bool err_status= TRUE;
sp_head *sp;
1. Fix memory leak. 2. Use multibyte-safe constant.
2007-05-30 14:24:21 +02:00
sp_cache **cache = type == TYPE_ENUM_PROCEDURE ?
&thd->sp_proc_cache : &thd->sp_func_cache;
Refactoring patch: 1. Refactor sp_show_create_function() and sp_show_create_procedure() into show_create_routine(). 2. Code cleanup: eliminate proxy functions.
2007-05-29 19:22:33 +02:00
DBUG_ENTER("sp_show_create_routine");
Fix a warning.
2007-06-01 12:17:23 +02:00
DBUG_PRINT("enter", ("name: %.*s",
(int) name->m_name.length,
name->m_name.str));
Refactoring patch: 1. Refactor sp_show_create_function() and sp_show_create_procedure() into show_create_routine(). 2. Code cleanup: eliminate proxy functions.
2007-05-29 19:22:33 +02:00
DBUG_ASSERT(type == TYPE_ENUM_PROCEDURE ||
type == TYPE_ENUM_FUNCTION);
if (type == TYPE_ENUM_PROCEDURE)
{
/*
SHOW CREATE PROCEDURE may require two instances of one sp_head
object when SHOW CREATE PROCEDURE is called for the procedure that
is being executed. Basically, there is no actual recursion, so we
increase the recursion limit for this statement (kind of hack).
SHOW CREATE FUNCTION does not require this because SHOW CREATE
statements are prohibitted within stored functions.
*/
thd->variables.max_sp_recursion_depth++;
}
1. Fix memory leak. 2. Use multibyte-safe constant.
2007-05-30 14:24:21 +02:00
if ((sp= sp_find_routine(thd, type, name, cache, FALSE)))
Refactoring patch: 1. Refactor sp_show_create_function() and sp_show_create_procedure() into show_create_routine(). 2. Code cleanup: eliminate proxy functions.
2007-05-29 19:22:33 +02:00
err_status= sp->show_create_routine(thd, type);
if (type == TYPE_ENUM_PROCEDURE)
thd->variables.max_sp_recursion_depth--;
DBUG_RETURN(err_status);
}
Most of the groundwork for sprint task 729 (implement FUNCTIONs). Expanded the mysql.proc table, reworked the find/create/drop functions completely, added new functions for FUNCTIONs (lotta functions here :), got rid of some unnecessary use of Item_strings while at it. Extended the parser correspondingly, and fiddled around a bit to make SP FUNCTIONs coexist with UDFs. Can now CREATE and DROP FUNCTIONs. Invoking yet to come...
2003-02-21 17:37:05 +01:00
Doxygenized comments.
2007-10-11 20:37:45 +02:00
/**
Recursion support made for SP (BUG#10100).
2005-11-23 00:11:19 +01:00
Obtain object representing stored procedure/function by its name from
Better approach for prelocking of tables for stored routines execution and some SP-related cleanups. - We don't have separate stage for calculation of list of tables to be prelocked and doing implicit LOCK/UNLOCK any more. Instead we calculate this list at open_tables() and do implicit LOCK in lock_tables() (and UNLOCK in close_thread_tables()). Also now we support cases when same table (with same alias) is used several times in the same query in SP. - Cleaned up execution of SP. Moved all common code which handles LEX and does preparations before statement execution or complex expression evaluation to auxilary sp_lex_keeper class. Now all statements in SP (and corresponding instructions) that evaluate expression which can contain subquery have their own LEX.
2005-03-04 14:35:28 +01:00
stored procedures cache and looking into mysql.proc if needed.
Doxygenized comments.
2007-10-11 20:37:45 +02:00
@param thd thread context
@param type type of object (TYPE_ENUM_FUNCTION or TYPE_ENUM_PROCEDURE)
@param name name of procedure
@param cp hash to look routine in
@param cache_only if true perform cache-only lookup
(Don't look in mysql.proc).
@retval
NonNULL pointer to sp_head object for the procedure
@retval
NULL in case of error.
Better approach for prelocking of tables for stored routines execution and some SP-related cleanups. - We don't have separate stage for calculation of list of tables to be prelocked and doing implicit LOCK/UNLOCK any more. Instead we calculate this list at open_tables() and do implicit LOCK in lock_tables() (and UNLOCK in close_thread_tables()). Also now we support cases when same table (with same alias) is used several times in the same query in SP. - Cleaned up execution of SP. Moved all common code which handles LEX and does preparations before statement execution or complex expression evaluation to auxilary sp_lex_keeper class. Now all statements in SP (and corresponding instructions) that evaluate expression which can contain subquery have their own LEX.
2005-03-04 14:35:28 +01:00
*/
Most of the groundwork for sprint task 729 (implement FUNCTIONs). Expanded the mysql.proc table, reworked the find/create/drop functions completely, added new functions for FUNCTIONs (lotta functions here :), got rid of some unnecessary use of Item_strings while at it. Extended the parser correspondingly, and fiddled around a bit to make SP FUNCTIONs coexist with UDFs. Can now CREATE and DROP FUNCTIONs. Invoking yet to come...
2003-02-21 17:37:05 +01:00
sp_head *
Recursion support made for SP (BUG#10100).
2005-11-23 00:11:19 +01:00
sp_find_routine(THD *thd, int type, sp_name *name, sp_cache **cp,
bool cache_only)
Most of the groundwork for sprint task 729 (implement FUNCTIONs). Expanded the mysql.proc table, reworked the find/create/drop functions completely, added new functions for FUNCTIONs (lotta functions here :), got rid of some unnecessary use of Item_strings while at it. Extended the parser correspondingly, and fiddled around a bit to make SP FUNCTIONs coexist with UDFs. Can now CREATE and DROP FUNCTIONs. Invoking yet to come...
2003-02-21 17:37:05 +01:00
{
sp_head *sp;
Recursion support made for SP (BUG#10100).
2005-11-23 00:11:19 +01:00
ulong depth= (type == TYPE_ENUM_PROCEDURE ?
thd->variables.max_sp_recursion_depth :
0);
DBUG_ENTER("sp_find_routine");
WL#3817: Simplify string / memory area types and make things more consistent (first part) The following type conversions was done: - Changed byte to uchar - Changed gptr to uchar* - Change my_string to char * - Change my_size_t to size_t - Change size_s to size_t Removed declaration of byte, gptr, my_string, my_size_t and size_s. Following function parameter changes was done: - All string functions in mysys/strings was changed to use size_t instead of uint for string lengths. - All read()/write() functions changed to use size_t (including vio). - All protocoll functions changed to use size_t instead of uint - Functions that used a pointer to a string length was changed to use size_t* - Changed malloc(), free() and related functions from using gptr to use void * as this requires fewer casts in the code and is more in line with how the standard functions work. - Added extra length argument to dirname_part() to return the length of the created string. - Changed (at least) following functions to take uchar* as argument: - db_dump() - my_net_write() - net_write_command() - net_store_data() - DBUG_DUMP() - decimal2bin() & bin2decimal() - Changed my_compress() and my_uncompress() to use size_t. Changed one argument to my_uncompress() from a pointer to a value as we only return one value (makes function easier to use). - Changed type of 'pack_data' argument to packfrm() to avoid casts. - Changed in readfrm() and writefrom(), ha_discover and handler::discover() the type for argument 'frmdata' to uchar** to avoid casts. - Changed most Field functions to use uchar* instead of char* (reduced a lot of casts). - Changed field->val_xxx(xxx, new_ptr) to take const pointers. Other changes: - Removed a lot of not needed casts - Added a few new cast required by other changes - Added some cast to my_multi_malloc() arguments for safety (as string lengths needs to be uint, not size_t). - Fixed all calls to hash-get-key functions to use size_t*. (Needed to be done explicitely as this conflict was often hided by casting the function to hash_get_key). - Changed some buffers to memory regions to uchar* to avoid casts. - Changed some string lengths from uint to size_t. - Changed field->ptr to be uchar* instead of char*. This allowed us to get rid of a lot of casts. - Some changes from true -> TRUE, false -> FALSE, unsigned char -> uchar - Include zlib.h in some files as we needed declaration of crc32() - Changed MY_FILE_ERROR to be (size_t) -1. - Changed many variables to hold the result of my_read() / my_write() to be size_t. This was needed to properly detect errors (which are returned as (size_t) -1). - Removed some very old VMS code - Changed packfrm()/unpackfrm() to not be depending on uint size (portability fix) - Removed windows specific code to restore cursor position as this causes slowdown on windows and we should not mix read() and pread() calls anyway as this is not thread safe. Updated function comment to reflect this. Changed function that depended on original behavior of my_pwrite() to itself restore the cursor position (one such case). - Added some missing checking of return value of malloc(). - Changed definition of MOD_PAD_CHAR_TO_FULL_LENGTH to avoid 'long' overflow. - Changed type of table_def::m_size from my_size_t to ulong to reflect that m_size is the number of elements in the array, not a string/memory length. - Moved THD::max_row_length() to table.cc (as it's not depending on THD). Inlined max_row_length_blob() into this function. - More function comments - Fixed some compiler warnings when compiled without partitions. - Removed setting of LEX_STRING() arguments in declaration (portability fix). - Some trivial indentation/variable name changes. - Some trivial code simplifications: - Replaced some calls to alloc_root + memcpy to use strmake_root()/strdup_root(). - Changed some calls from memdup() to strmake() (Safety fix) - Simpler loops in client-simple.c
2007-05-10 11:59:39 +02:00
DBUG_PRINT("enter", ("name: %.*s.%.*s type: %d cache only %d",
(int) name->m_db.length, name->m_db.str,
(int) name->m_name.length, name->m_name.str,
Recursion support made for SP (BUG#10100).
2005-11-23 00:11:19 +01:00
type, cache_only));
Most of the groundwork for sprint task 729 (implement FUNCTIONs). Expanded the mysql.proc table, reworked the find/create/drop functions completely, added new functions for FUNCTIONs (lotta functions here :), got rid of some unnecessary use of Item_strings while at it. Extended the parser correspondingly, and fiddled around a bit to make SP FUNCTIONs coexist with UDFs. Can now CREATE and DROP FUNCTIONs. Invoking yet to come...
2003-02-21 17:37:05 +01:00
Recursion support made for SP (BUG#10100).
2005-11-23 00:11:19 +01:00
if ((sp= sp_cache_lookup(cp, name)))
SP cache (WL#730). (Mostly by vva, additions by pem.)
2003-07-01 18:14:24 +02:00
{
Recursion support made for SP (BUG#10100).
2005-11-23 00:11:19 +01:00
ulong level;
Review fixes of new pushed code - Fixed tests - Optimized new code - Fixed some unlikely core dumps - Better bug fixes for: - #14397 - OPTIMIZE TABLE with an open HANDLER causes a crash - #14850 (ERROR 1062 when a quering a view using a Group By on a column that can be null
2006-01-05 23:47:49 +01:00
sp_head *new_sp;
const char *returns= "";
Fix for BUG#15110: mysqldump --triggers: does not include DEFINER clause There are two main idea of this fix: - introduce a common function for server and client to split user value (<user name>@<host name>) into user name and host name parts; - dump DEFINER clause in correct format in mysqldump.
2006-01-11 00:07:40 +01:00
char definer[USER_HOST_BUFF_SIZE];
Fix for BUG#16211: Stored function return type for strings is ignored. Fix for BUG#16676: Database CHARSET not used for stored procedures The problem in BUG#16211 is that CHARSET-clause of the return type for stored functions is just ignored. The problem in BUG#16676 is that if character set is not explicitly specified for sp-variable, the server character set is used instead of the database one. The fix has two parts: - always store CHARSET-clause of the return type along with the type definition in mysql.proc.returns column. "Always" means that CHARSET-clause is appended even if it has not been explicitly specified in CREATE FUNCTION statement (this affects BUG#16211 only). Storing CHARSET-clause if it is not specified is essential to avoid changing character set if the database character set is altered in the future. NOTE: this change is not backward compatible with the previous releases. - use database default character set if CHARSET-clause is not explicitly specified (this affects both BUG#16211 and BUG#16676). NOTE: this also breaks backward compatibility.
2006-07-27 15:57:43 +02:00
/*
String buffer for RETURNS data type must have system charset;
64 -- size of "returns" column of mysql.proc.
*/
Review fixes of new pushed code - Fixed tests - Optimized new code - Fixed some unlikely core dumps - Better bug fixes for: - #14397 - OPTIMIZE TABLE with an open HANDLER causes a crash - #14850 (ERROR 1062 when a quering a view using a Group By on a column that can be null
2006-01-05 23:47:49 +01:00
String retstr(64);
Recursion support made for SP (BUG#10100).
2005-11-23 00:11:19 +01:00
DBUG_PRINT("info", ("found: 0x%lx", (ulong)sp));
if (sp->m_first_free_instance)
{
After merge fixes Removed a lot of compiler warnings Removed not used variables, functions and labels Initialize some variables that could be used unitialized (fatal bugs) %ll -> %l
2007-01-29 00:47:35 +01:00
DBUG_PRINT("info", ("first free: 0x%lx level: %lu flags %x",
Recursion support made for SP (BUG#10100).
2005-11-23 00:11:19 +01:00
(ulong)sp->m_first_free_instance,
sp->m_first_free_instance->m_recursion_level,
sp->m_first_free_instance->m_flags));
DBUG_ASSERT(!(sp->m_first_free_instance->m_flags & sp_head::IS_INVOKED));
if (sp->m_first_free_instance->m_recursion_level > depth)
{
Review fixes of new pushed code - Fixed tests - Optimized new code - Fixed some unlikely core dumps - Better bug fixes for: - #14397 - OPTIMIZE TABLE with an open HANDLER causes a crash - #14850 (ERROR 1062 when a quering a view using a Group By on a column that can be null
2006-01-05 23:47:49 +01:00
sp->recursion_level_error(thd);
Recursion support made for SP (BUG#10100).
2005-11-23 00:11:19 +01:00
DBUG_RETURN(0);
}
DBUG_RETURN(sp->m_first_free_instance);
}
Fix for bug#21416 SP: Recursion level higher than zero needed for non-recursive call The following procedure was not possible if max_sp_recursion_depth is 0 create procedure show_proc() show create procedure show_proc; Actually there is no recursive call but the limit is checked. Solved by temporarily increasing the thread's limit just before the fetch from cache and decreasing after that.
2006-08-24 19:36:26 +02:00
/*
Actually depth could be +1 than the actual value in case a SP calls
SHOW CREATE PROCEDURE. Hence, the linked list could hold up to one more
instance.
*/
Fix for bug#21416 SP: Recursion level higher than zero needed for non-recursive call The following procedure was not possible if max_sp_recursion_depth is 0 create procedure show_proc() show create procedure show_proc; Actually there is no recursive call but the limit is checked. Solved by temporarily increasing the thread's limit just before the fetch from cache and decreasing after that.
2006-08-04 12:50:49 +02:00
Recursion support made for SP (BUG#10100).
2005-11-23 00:11:19 +01:00
level= sp->m_last_cached_sp->m_recursion_level + 1;
if (level > depth)
{
Review fixes of new pushed code - Fixed tests - Optimized new code - Fixed some unlikely core dumps - Better bug fixes for: - #14397 - OPTIMIZE TABLE with an open HANDLER causes a crash - #14850 (ERROR 1062 when a quering a view using a Group By on a column that can be null
2006-01-05 23:47:49 +01:00
sp->recursion_level_error(thd);
Recursion support made for SP (BUG#10100).
2005-11-23 00:11:19 +01:00
DBUG_RETURN(0);
}
Review fixes of new pushed code - Fixed tests - Optimized new code - Fixed some unlikely core dumps - Better bug fixes for: - #14397 - OPTIMIZE TABLE with an open HANDLER causes a crash - #14850 (ERROR 1062 when a quering a view using a Group By on a column that can be null
2006-01-05 23:47:49 +01:00
strxmov(definer, sp->m_definer_user.str, "@",
sp->m_definer_host.str, NullS);
if (type == TYPE_ENUM_FUNCTION)
Recursion support made for SP (BUG#10100).
2005-11-23 00:11:19 +01:00
{
Review fixes of new pushed code - Fixed tests - Optimized new code - Fixed some unlikely core dumps - Better bug fixes for: - #14397 - OPTIMIZE TABLE with an open HANDLER causes a crash - #14850 (ERROR 1062 when a quering a view using a Group By on a column that can be null
2006-01-05 23:47:49 +01:00
sp_returns_type(thd, retstr, sp);
returns= retstr.ptr();
}
if (db_load_routine(thd, type, name, &new_sp,
sp->m_sql_mode, sp->m_params.str, returns,
sp->m_body.str, *sp->m_chistics, definer,
Patch for the following bugs: - BUG#11986: Stored routines and triggers can fail if the code has a non-ascii symbol - BUG#16291: mysqldump corrupts string-constants with non-ascii-chars - BUG#19443: INFORMATION_SCHEMA does not support charsets properly - BUG#21249: Character set of SP-var can be ignored - BUG#25212: Character set of string constant is ignored (stored routines) - BUG#25221: Character set of string constant is ignored (triggers) There were a few general problems that caused these bugs: 1. Character set information of the original (definition) query for views, triggers, stored routines and events was lost. 2. mysqldump output query in client character set, which can be inappropriate to encode definition-query. 3. INFORMATION_SCHEMA used strings with mixed encodings to display object definition; 1. No query-definition-character set. In order to compile query into execution code, some extra data (such as environment variables or the database character set) is used. The problem here was that this context was not preserved. So, on the next load it can differ from the original one, thus the result will be different. The context contains the following data: - client character set; - connection collation (character set and collation); - collation of the owner database; The fix is to store this context and use it each time we parse (compile) and execute the object (stored routine, trigger, ...). 2. Wrong mysqldump-output. The original query can contain several encodings (by means of character set introducers). The problem here was that we tried to convert original query to the mysqldump-client character set. Moreover, we stored queries in different character sets for different objects (views, for one, used UTF8, triggers used original character set). The solution is - to store definition queries in the original character set; - to change SHOW CREATE statement to output definition query in the binary character set (i.e. without any conversion); - introduce SHOW CREATE TRIGGER statement; - to dump special statements to switch the context to the original one before dumping and restore it afterwards. Note, in order to preserve the database collation at the creation time, additional ALTER DATABASE might be used (to temporary switch the database collation back to the original value). In this case, ALTER DATABASE privilege will be required. This is a backward-incompatible change. 3. INFORMATION_SCHEMA showed non-UTF8 strings The fix is to generate UTF8-query during the parsing, store it in the object and show it in the INFORMATION_SCHEMA. Basically, the idea is to create a copy of the original query convert it to UTF8. Character set introducers are removed and all text literals are converted to UTF8. This UTF8 query is intended to provide user-readable output. It must not be used to recreate the object. Specialized SHOW CREATE statements should be used for this. The reason for this limitation is the following: the original query can contain symbols from several character sets (by means of character set introducers). Example: - original query: CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1; - UTF8 query (for INFORMATION_SCHEMA): CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 19:34:54 +02:00
sp->m_created, sp->m_modified,
sp->get_creation_ctx()) == SP_OK)
Review fixes of new pushed code - Fixed tests - Optimized new code - Fixed some unlikely core dumps - Better bug fixes for: - #14397 - OPTIMIZE TABLE with an open HANDLER causes a crash - #14850 (ERROR 1062 when a quering a view using a Group By on a column that can be null
2006-01-05 23:47:49 +01:00
{
sp->m_last_cached_sp->m_next_cached_sp= new_sp;
new_sp->m_recursion_level= level;
new_sp->m_first_instance= sp;
sp->m_last_cached_sp= sp->m_first_free_instance= new_sp;
DBUG_PRINT("info", ("added level: 0x%lx, level: %lu, flags %x",
Recursion support made for SP (BUG#10100).
2005-11-23 00:11:19 +01:00
(ulong)new_sp, new_sp->m_recursion_level,
new_sp->m_flags));
Review fixes of new pushed code - Fixed tests - Optimized new code - Fixed some unlikely core dumps - Better bug fixes for: - #14397 - OPTIMIZE TABLE with an open HANDLER causes a crash - #14850 (ERROR 1062 when a quering a view using a Group By on a column that can be null
2006-01-05 23:47:49 +01:00
DBUG_RETURN(new_sp);
Recursion support made for SP (BUG#10100).
2005-11-23 00:11:19 +01:00
}
Review fixes of new pushed code - Fixed tests - Optimized new code - Fixed some unlikely core dumps - Better bug fixes for: - #14397 - OPTIMIZE TABLE with an open HANDLER causes a crash - #14850 (ERROR 1062 when a quering a view using a Group By on a column that can be null
2006-01-05 23:47:49 +01:00
DBUG_RETURN(0);
Recursion support made for SP (BUG#10100).
2005-11-23 00:11:19 +01:00
}
if (!cache_only)
SP cache (WL#730). (Mostly by vva, additions by pem.)
2003-07-01 18:14:24 +02:00
{
Recursion support made for SP (BUG#10100).
2005-11-23 00:11:19 +01:00
if (db_find_routine(thd, type, name, &sp) == SP_OK)
{
sp_cache_insert(cp, sp);
DBUG_PRINT("info", ("added new: 0x%lx, level: %lu, flags %x",
(ulong)sp, sp->m_recursion_level,
sp->m_flags));
}
SP cache (WL#730). (Mostly by vva, additions by pem.)
2003-07-01 18:14:24 +02:00
}
Most of the groundwork for sprint task 729 (implement FUNCTIONs). Expanded the mysql.proc table, reworked the find/create/drop functions completely, added new functions for FUNCTIONs (lotta functions here :), got rid of some unnecessary use of Item_strings while at it. Extended the parser correspondingly, and fiddled around a bit to make SP FUNCTIONs coexist with UDFs. Can now CREATE and DROP FUNCTIONs. Invoking yet to come...
2003-02-21 17:37:05 +01:00
DBUG_RETURN(sp);
}
Fixed memory leaks in SP Some code cleanup
2003-12-21 11:48:03 +01:00
Doxygenized comments.
2007-10-11 20:37:45 +02:00
/**
Fixed BUG#16303: erroneus stored procedures and functions should be droppable Use a special lookup function for DROP, which doesn't attempt to parse the definition.
2006-01-26 13:29:46 +01:00
This is used by sql_acl.cc:mysql_routine_grant() and is used to find
the routines in 'routines'.
Bug#44658 Create procedure makes server crash when user does not have ALL privilege MySQL crashes if a user without proper privileges attempts to create a procedure. The crash happens because more than one error state is pushed onto the Diagnostic area. In this particular case the user is denied to implicitly create a new user account with the implicitly granted privileges ALTER- and EXECUTE ROUTINE. The new account is needed if the original user account contained a host mask. A user account with a host mask is a distinct user account in this context. An alternative would be to first get the most permissive user account which include the current user connection and then assign privileges to that account. This behavior change is considered out of scope for this bug patch. The implicit assignment of privileges when a user creates a stored routine is a considered to be a feature for user convenience and as such it is not a critical operation. Any failure to complete this operation is thus considered non-fatal (an error becomes a warning). The patch back ports a stack implementation of the internal error handler interface. This enables the use of multiple error handlers so that it is possible to intercept and cancel errors thrown by lower layers. This is needed as a error handler already is used in the call stack emitting the errors which needs to be converted.
2009-05-29 15:37:54 +02:00
@param thd Thread handler
@param routines List of needles in the hay stack
@param any Any of the needles are good enough
@return
@retval FALSE Found.
@retval TRUE Not found
Fixed BUG#16303: erroneus stored procedures and functions should be droppable Use a special lookup function for DROP, which doesn't attempt to parse the definition.
2006-01-26 13:29:46 +01:00
*/
Recursion support made for SP (BUG#10100).
2005-11-23 00:11:19 +01:00
Bug#44658 Create procedure makes server crash when user does not have ALL privilege MySQL crashes if a user without proper privileges attempts to create a procedure. The crash happens because more than one error state is pushed onto the Diagnostic area. In this particular case the user is denied to implicitly create a new user account with the implicitly granted privileges ALTER- and EXECUTE ROUTINE. The new account is needed if the original user account contained a host mask. A user account with a host mask is a distinct user account in this context. An alternative would be to first get the most permissive user account which include the current user connection and then assign privileges to that account. This behavior change is considered out of scope for this bug patch. The implicit assignment of privileges when a user creates a stored routine is a considered to be a feature for user convenience and as such it is not a critical operation. Any failure to complete this operation is thus considered non-fatal (an error becomes a warning). The patch back ports a stack implementation of the internal error handler interface. This enables the use of multiple error handlers so that it is possible to intercept and cancel errors thrown by lower layers. This is needed as a error handler already is used in the call stack emitting the errors which needs to be converted.
2009-05-29 15:37:54 +02:00
bool
sp_exist_routines(THD *thd, TABLE_LIST *routines, bool any)
WL#925 - Privileges for stored routines Implement fine-grained control over access to stored procedures Privileges are cached (same way as existing table/column privs)
2004-12-23 11:46:24 +01:00
{
Fixed BUG#16303: erroneus stored procedures and functions should be droppable Use a special lookup function for DROP, which doesn't attempt to parse the definition.
2006-01-26 13:29:46 +01:00
TABLE_LIST *routine;
Fix for BUG#7787: Stored procedures: improper warning for "grant execute" statement. The problem was that error flag was not reset.
2006-02-22 11:44:04 +01:00
bool sp_object_found;
WL#925 - Privileges for stored routines Implement fine-grained control over access to stored procedures Privileges are cached (same way as existing table/column privs)
2004-12-23 11:46:24 +01:00
DBUG_ENTER("sp_exists_routine");
Fixed BUG#16303: erroneus stored procedures and functions should be droppable Use a special lookup function for DROP, which doesn't attempt to parse the definition.
2006-01-26 13:29:46 +01:00
for (routine= routines; routine; routine= routine->next_global)
WL#925 - Privileges for stored routines Implement fine-grained control over access to stored procedures Privileges are cached (same way as existing table/column privs)
2004-12-23 11:46:24 +01:00
{
sp_name *name;
LEX_STRING lex_db;
LEX_STRING lex_name;
Fixed BUG#16303: erroneus stored procedures and functions should be droppable Use a special lookup function for DROP, which doesn't attempt to parse the definition.
2006-01-26 13:29:46 +01:00
lex_db.length= strlen(routine->db);
lex_name.length= strlen(routine->table_name);
lex_db.str= thd->strmake(routine->db, lex_db.length);
lex_name.str= thd->strmake(routine->table_name, lex_name.length);
Bug#23491 MySQLDump prefix function call in a view by database name - mysqldump executes a SHOW CREATE VIEW statement to generate the text that it outputs. When the function name is retrieved it's database name is unconditionally prepended. This change causes the function's database name to be prepended only when it was used to define the function.
2007-03-27 18:31:44 +02:00
name= new sp_name(lex_db, lex_name, true);
WL#925 - Privileges for stored routines Implement fine-grained control over access to stored procedures Privileges are cached (same way as existing table/column privs)
2004-12-23 11:46:24 +01:00
name->init_qname(thd);
Fix for BUG#7787: Stored procedures: improper warning for "grant execute" statement. The problem was that error flag was not reset.
2006-02-22 11:44:04 +01:00
sp_object_found= sp_find_routine(thd, TYPE_ENUM_PROCEDURE, name,
&thd->sp_proc_cache, FALSE) != NULL ||
sp_find_routine(thd, TYPE_ENUM_FUNCTION, name,
&thd->sp_func_cache, FALSE) != NULL;
mysql_reset_errors(thd, TRUE);
if (sp_object_found)
WL#925 - Privileges for stored routines Implement fine-grained control over access to stored procedures Privileges are cached (same way as existing table/column privs)
2004-12-23 11:46:24 +01:00
{
if (any)
Bug#44658 Create procedure makes server crash when user does not have ALL privilege MySQL crashes if a user without proper privileges attempts to create a procedure. The crash happens because more than one error state is pushed onto the Diagnostic area. In this particular case the user is denied to implicitly create a new user account with the implicitly granted privileges ALTER- and EXECUTE ROUTINE. The new account is needed if the original user account contained a host mask. A user account with a host mask is a distinct user account in this context. An alternative would be to first get the most permissive user account which include the current user connection and then assign privileges to that account. This behavior change is considered out of scope for this bug patch. The implicit assignment of privileges when a user creates a stored routine is a considered to be a feature for user convenience and as such it is not a critical operation. Any failure to complete this operation is thus considered non-fatal (an error becomes a warning). The patch back ports a stack implementation of the internal error handler interface. This enables the use of multiple error handlers so that it is possible to intercept and cancel errors thrown by lower layers. This is needed as a error handler already is used in the call stack emitting the errors which needs to be converted.
2009-05-29 15:37:54 +02:00
break;
WL#925 - Privileges for stored routines Implement fine-grained control over access to stored procedures Privileges are cached (same way as existing table/column privs)
2004-12-23 11:46:24 +01:00
}
else if (!any)
{
Bug#44658 Create procedure makes server crash when user does not have ALL privilege MySQL crashes if a user without proper privileges attempts to create a procedure. The crash happens because more than one error state is pushed onto the Diagnostic area. In this particular case the user is denied to implicitly create a new user account with the implicitly granted privileges ALTER- and EXECUTE ROUTINE. The new account is needed if the original user account contained a host mask. A user account with a host mask is a distinct user account in this context. An alternative would be to first get the most permissive user account which include the current user connection and then assign privileges to that account. This behavior change is considered out of scope for this bug patch. The implicit assignment of privileges when a user creates a stored routine is a considered to be a feature for user convenience and as such it is not a critical operation. Any failure to complete this operation is thus considered non-fatal (an error becomes a warning). The patch back ports a stack implementation of the internal error handler interface. This enables the use of multiple error handlers so that it is possible to intercept and cancel errors thrown by lower layers. This is needed as a error handler already is used in the call stack emitting the errors which needs to be converted.
2009-05-29 15:37:54 +02:00
my_error(ER_SP_DOES_NOT_EXIST, MYF(0), "FUNCTION or PROCEDURE",
routine->table_name);
DBUG_RETURN(TRUE);
WL#925 - Privileges for stored routines Implement fine-grained control over access to stored procedures Privileges are cached (same way as existing table/column privs)
2004-12-23 11:46:24 +01:00
}
}
Bug#44658 Create procedure makes server crash when user does not have ALL privilege MySQL crashes if a user without proper privileges attempts to create a procedure. The crash happens because more than one error state is pushed onto the Diagnostic area. In this particular case the user is denied to implicitly create a new user account with the implicitly granted privileges ALTER- and EXECUTE ROUTINE. The new account is needed if the original user account contained a host mask. A user account with a host mask is a distinct user account in this context. An alternative would be to first get the most permissive user account which include the current user connection and then assign privileges to that account. This behavior change is considered out of scope for this bug patch. The implicit assignment of privileges when a user creates a stored routine is a considered to be a feature for user convenience and as such it is not a critical operation. Any failure to complete this operation is thus considered non-fatal (an error becomes a warning). The patch back ports a stack implementation of the internal error handler interface. This enables the use of multiple error handlers so that it is possible to intercept and cancel errors thrown by lower layers. This is needed as a error handler already is used in the call stack emitting the errors which needs to be converted.
2009-05-29 15:37:54 +02:00
DBUG_RETURN(FALSE);
WL#925 - Privileges for stored routines Implement fine-grained control over access to stored procedures Privileges are cached (same way as existing table/column privs)
2004-12-23 11:46:24 +01:00
}
Doxygenized comments.
2007-10-11 20:37:45 +02:00
/**
Fixed BUG#16303: erroneus stored procedures and functions should be droppable Use a special lookup function for DROP, which doesn't attempt to parse the definition.
2006-01-26 13:29:46 +01:00
Check if a routine exists in the mysql.proc table, without actually
Doxygenized comments.
2007-10-11 20:37:45 +02:00
parsing the definition. (Used for dropping).
Fixed BUG#16303: erroneus stored procedures and functions should be droppable Use a special lookup function for DROP, which doesn't attempt to parse the definition.
2006-01-26 13:29:46 +01:00
Doxygenized comments.
2007-10-11 20:37:45 +02:00
@param thd thread context
@param name name of procedure
Fixed BUG#16303: erroneus stored procedures and functions should be droppable Use a special lookup function for DROP, which doesn't attempt to parse the definition.
2006-01-26 13:29:46 +01:00
Doxygenized comments.
2007-10-11 20:37:45 +02:00
@retval
0 Success
@retval
non-0 Error; SP_OPEN_TABLE_FAILED or SP_KEY_NOT_FOUND
Fixed BUG#16303: erroneus stored procedures and functions should be droppable Use a special lookup function for DROP, which doesn't attempt to parse the definition.
2006-01-26 13:29:46 +01:00
*/
int
sp_routine_exists_in_table(THD *thd, int type, sp_name *name)
{
TABLE *table;
int ret;
Open_tables_state open_tables_state_backup;
if (!(table= open_proc_table_for_read(thd, &open_tables_state_backup)))
ret= SP_OPEN_TABLE_FAILED;
else
{
Minor fix for BUG#16303 in sp.cc: Simplified code in sp_routine_exists_in_table(). (No change of functionality)
2006-02-02 15:37:29 +01:00
if ((ret= db_find_routine_aux(thd, type, name, table)) != SP_OK)
Fixed BUG#16303: erroneus stored procedures and functions should be droppable Use a special lookup function for DROP, which doesn't attempt to parse the definition.
2006-01-26 13:29:46 +01:00
ret= SP_KEY_NOT_FOUND;
BUG#9953: CONVERT_TZ requires mysql.time_zone_name to be locked The problem was that some facilities (like CONVERT_TZ() function or server HELP statement) may require implicit access to some tables in 'mysql' database. This access was done by ordinary means of adding such tables to the list of tables the query is going to open. However, if we issued LOCK TABLES before that, we would get "table was not locked" error trying to open such implicit tables. The solution is to treat certain tables as MySQL system tables, like we already do for mysql.proc. Such tables may be opened for reading at any moment regardless of any locks in effect. The cost of this is that system table may be locked for writing only together with other system tables, it is disallowed to lock system tables for writing and have any other lock on any other table. After this patch the following tables are treated as MySQL system tables: mysql.help_category mysql.help_keyword mysql.help_relation mysql.help_topic mysql.proc (it already was) mysql.time_zone mysql.time_zone_leap_second mysql.time_zone_name mysql.time_zone_transition mysql.time_zone_transition_type These tables are now opened with open_system_tables_for_read() and closed with close_system_tables(), or one table may be opened with open_system_table_for_update() and closed with close_thread_tables() (the latter is used for mysql.proc table, which is updated as part of normal MySQL server operation). These functions may be used when some tables were opened and locked already. NOTE: online update of time zone tables is not possible during replication, because there's no time zone cache flush neither on LOCK TABLES, nor on FLUSH TABLES, so the master may serve stale time zone data from cache, while on slave updated data will be loaded from the time zone tables.
2007-03-09 11:12:31 +01:00
close_system_tables(thd, &open_tables_state_backup);
Fixed BUG#16303: erroneus stored procedures and functions should be droppable Use a special lookup function for DROP, which doesn't attempt to parse the definition.
2006-01-26 13:29:46 +01:00
}
return ret;
}
Doxygenized comments.
2007-10-11 20:37:45 +02:00
/**
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
Structure that represents element in the set of stored routines
used by statement or routine.
*/
struct Sroutine_hash_entry;
struct Sroutine_hash_entry
Fixed the old kludge for pre-loading functions and made it more efficient using a hash table instead (and made it work with lex pointers). Some additional code cleanup too.
2003-07-07 14:55:10 +02:00
{
Doxygenized comments.
2007-10-11 20:37:45 +02:00
/**
Set key consisting of one-byte routine type and quoted routine name.
*/
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
LEX_STRING key;
Doxygenized comments.
2007-10-11 20:37:45 +02:00
/**
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
Next element in list linking all routines in set. See also comments
for LEX::sroutine/sroutine_list and sp_head::m_sroutines.
*/
Sroutine_hash_entry *next;
Doxygenized comments.
2007-10-11 20:37:45 +02:00
/**
Fix for bug #11555 "Stored procedures: current SP tables locking make impossible view security". We should not expose names of tables which are explicitly or implicitly (via routine or trigger) used by view even if we find that they are missing. So during building of list of prelocked tables for statement we track which routines (and therefore tables for these routines) are used from views. We mark elements of LEX::routines set which correspond to routines used in views by setting Sroutine_hash_entry::belong_to_view member to point to TABLE_LIST object for topmost view which uses routine. We propagate this mark to all routines which are used by this routine and which we add to this set. We also mark tables used by such routine which we add to the list of tables for prelocking as belonging to this view.
2005-12-07 10:27:17 +01:00
Uppermost view which directly or indirectly uses this routine.
0 if routine is not used in view. Note that it also can be 0 if
statement uses routine both via view and directly.
*/
TABLE_LIST *belong_to_view;
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
};
WL#3817: Simplify string / memory area types and make things more consistent (first part) The following type conversions was done: - Changed byte to uchar - Changed gptr to uchar* - Change my_string to char * - Change my_size_t to size_t - Change size_s to size_t Removed declaration of byte, gptr, my_string, my_size_t and size_s. Following function parameter changes was done: - All string functions in mysys/strings was changed to use size_t instead of uint for string lengths. - All read()/write() functions changed to use size_t (including vio). - All protocoll functions changed to use size_t instead of uint - Functions that used a pointer to a string length was changed to use size_t* - Changed malloc(), free() and related functions from using gptr to use void * as this requires fewer casts in the code and is more in line with how the standard functions work. - Added extra length argument to dirname_part() to return the length of the created string. - Changed (at least) following functions to take uchar* as argument: - db_dump() - my_net_write() - net_write_command() - net_store_data() - DBUG_DUMP() - decimal2bin() & bin2decimal() - Changed my_compress() and my_uncompress() to use size_t. Changed one argument to my_uncompress() from a pointer to a value as we only return one value (makes function easier to use). - Changed type of 'pack_data' argument to packfrm() to avoid casts. - Changed in readfrm() and writefrom(), ha_discover and handler::discover() the type for argument 'frmdata' to uchar** to avoid casts. - Changed most Field functions to use uchar* instead of char* (reduced a lot of casts). - Changed field->val_xxx(xxx, new_ptr) to take const pointers. Other changes: - Removed a lot of not needed casts - Added a few new cast required by other changes - Added some cast to my_multi_malloc() arguments for safety (as string lengths needs to be uint, not size_t). - Fixed all calls to hash-get-key functions to use size_t*. (Needed to be done explicitely as this conflict was often hided by casting the function to hash_get_key). - Changed some buffers to memory regions to uchar* to avoid casts. - Changed some string lengths from uint to size_t. - Changed field->ptr to be uchar* instead of char*. This allowed us to get rid of a lot of casts. - Some changes from true -> TRUE, false -> FALSE, unsigned char -> uchar - Include zlib.h in some files as we needed declaration of crc32() - Changed MY_FILE_ERROR to be (size_t) -1. - Changed many variables to hold the result of my_read() / my_write() to be size_t. This was needed to properly detect errors (which are returned as (size_t) -1). - Removed some very old VMS code - Changed packfrm()/unpackfrm() to not be depending on uint size (portability fix) - Removed windows specific code to restore cursor position as this causes slowdown on windows and we should not mix read() and pread() calls anyway as this is not thread safe. Updated function comment to reflect this. Changed function that depended on original behavior of my_pwrite() to itself restore the cursor position (one such case). - Added some missing checking of return value of malloc(). - Changed definition of MOD_PAD_CHAR_TO_FULL_LENGTH to avoid 'long' overflow. - Changed type of table_def::m_size from my_size_t to ulong to reflect that m_size is the number of elements in the array, not a string/memory length. - Moved THD::max_row_length() to table.cc (as it's not depending on THD). Inlined max_row_length_blob() into this function. - More function comments - Fixed some compiler warnings when compiled without partitions. - Removed setting of LEX_STRING() arguments in declaration (portability fix). - Some trivial indentation/variable name changes. - Some trivial code simplifications: - Replaced some calls to alloc_root + memcpy to use strmake_root()/strdup_root(). - Changed some calls from memdup() to strmake() (Safety fix) - Simpler loops in client-simple.c
2007-05-10 11:59:39 +02:00
extern "C" uchar* sp_sroutine_key(const uchar *ptr, size_t *plen,
my_bool first)
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
{
Sroutine_hash_entry *rn= (Sroutine_hash_entry *)ptr;
*plen= rn->key.length;
WL#3817: Simplify string / memory area types and make things more consistent (first part) The following type conversions was done: - Changed byte to uchar - Changed gptr to uchar* - Change my_string to char * - Change my_size_t to size_t - Change size_s to size_t Removed declaration of byte, gptr, my_string, my_size_t and size_s. Following function parameter changes was done: - All string functions in mysys/strings was changed to use size_t instead of uint for string lengths. - All read()/write() functions changed to use size_t (including vio). - All protocoll functions changed to use size_t instead of uint - Functions that used a pointer to a string length was changed to use size_t* - Changed malloc(), free() and related functions from using gptr to use void * as this requires fewer casts in the code and is more in line with how the standard functions work. - Added extra length argument to dirname_part() to return the length of the created string. - Changed (at least) following functions to take uchar* as argument: - db_dump() - my_net_write() - net_write_command() - net_store_data() - DBUG_DUMP() - decimal2bin() & bin2decimal() - Changed my_compress() and my_uncompress() to use size_t. Changed one argument to my_uncompress() from a pointer to a value as we only return one value (makes function easier to use). - Changed type of 'pack_data' argument to packfrm() to avoid casts. - Changed in readfrm() and writefrom(), ha_discover and handler::discover() the type for argument 'frmdata' to uchar** to avoid casts. - Changed most Field functions to use uchar* instead of char* (reduced a lot of casts). - Changed field->val_xxx(xxx, new_ptr) to take const pointers. Other changes: - Removed a lot of not needed casts - Added a few new cast required by other changes - Added some cast to my_multi_malloc() arguments for safety (as string lengths needs to be uint, not size_t). - Fixed all calls to hash-get-key functions to use size_t*. (Needed to be done explicitely as this conflict was often hided by casting the function to hash_get_key). - Changed some buffers to memory regions to uchar* to avoid casts. - Changed some string lengths from uint to size_t. - Changed field->ptr to be uchar* instead of char*. This allowed us to get rid of a lot of casts. - Some changes from true -> TRUE, false -> FALSE, unsigned char -> uchar - Include zlib.h in some files as we needed declaration of crc32() - Changed MY_FILE_ERROR to be (size_t) -1. - Changed many variables to hold the result of my_read() / my_write() to be size_t. This was needed to properly detect errors (which are returned as (size_t) -1). - Removed some very old VMS code - Changed packfrm()/unpackfrm() to not be depending on uint size (portability fix) - Removed windows specific code to restore cursor position as this causes slowdown on windows and we should not mix read() and pread() calls anyway as this is not thread safe. Updated function comment to reflect this. Changed function that depended on original behavior of my_pwrite() to itself restore the cursor position (one such case). - Added some missing checking of return value of malloc(). - Changed definition of MOD_PAD_CHAR_TO_FULL_LENGTH to avoid 'long' overflow. - Changed type of table_def::m_size from my_size_t to ulong to reflect that m_size is the number of elements in the array, not a string/memory length. - Moved THD::max_row_length() to table.cc (as it's not depending on THD). Inlined max_row_length_blob() into this function. - More function comments - Fixed some compiler warnings when compiled without partitions. - Removed setting of LEX_STRING() arguments in declaration (portability fix). - Some trivial indentation/variable name changes. - Some trivial code simplifications: - Replaced some calls to alloc_root + memcpy to use strmake_root()/strdup_root(). - Changed some calls from memdup() to strmake() (Safety fix) - Simpler loops in client-simple.c
2007-05-10 11:59:39 +02:00
return (uchar *)rn->key.str;
Fixed the old kludge for pre-loading functions and made it more efficient using a hash table instead (and made it work with lex pointers). Some additional code cleanup too.
2003-07-07 14:55:10 +02:00
}
Fixed memory leaks in SP Some code cleanup
2003-12-21 11:48:03 +01:00
Doxygenized comments.
2007-10-11 20:37:45 +02:00
/**
Prelocking-free SPs, post-review fixes: * Don't activate prelocking mode for evaluating procedure arguments when it is not necessary. * Code structure simplification and cleanup. * Cleanup in .test files
2005-08-03 05:37:32 +02:00
Check if
- current statement (the one in thd->lex) needs table prelocking
- first routine in thd->lex->sroutines_list needs to execute its body in
prelocked mode.
Added Non-prelocked SP execution: Now a PROCEDURE doesn't enter/leave prelocked mode for its body, but lets each statement to get/release its own locks. This allows a broader set of statements to be executed inside PROCEDUREs (but breaks replication) This patch should fix BUG#8072, BUG#8766, BUG#9563, BUG#11126
2005-07-30 10:19:57 +02:00
Doxygenized comments.
2007-10-11 20:37:45 +02:00
@param thd Current thread, thd->lex is the statement to be
checked.
@param[out] need_prelocking TRUE - prelocked mode should be activated
before executing the statement;
FALSE - Don't activate prelocking
@param[out] first_no_prelocking TRUE - Tables used by first routine in
thd->lex->sroutines_list should be
prelocked. FALSE - Otherwise.
@note
Added Non-prelocked SP execution: Now a PROCEDURE doesn't enter/leave prelocked mode for its body, but lets each statement to get/release its own locks. This allows a broader set of statements to be executed inside PROCEDUREs (but breaks replication) This patch should fix BUG#8072, BUG#8766, BUG#9563, BUG#11126
2005-07-30 10:19:57 +02:00
This function assumes that for any "CALL proc(...)" statement routines_list
will have 'proc' as first element (it may have several, consider e.g.
"proc(sp_func(...)))". This property is currently guaranted by the parser.
*/
Prelocking-free SPs, post-review fixes: * Don't activate prelocking mode for evaluating procedure arguments when it is not necessary. * Code structure simplification and cleanup. * Cleanup in .test files
2005-08-03 05:37:32 +02:00
void sp_get_prelocking_info(THD *thd, bool *need_prelocking,
bool *first_no_prelocking)
Added Non-prelocked SP execution: Now a PROCEDURE doesn't enter/leave prelocked mode for its body, but lets each statement to get/release its own locks. This allows a broader set of statements to be executed inside PROCEDUREs (but breaks replication) This patch should fix BUG#8072, BUG#8766, BUG#9563, BUG#11126
2005-07-30 10:19:57 +02:00
{
Sroutine_hash_entry *routine;
Prelocking-free SPs, post-review fixes: * Don't activate prelocking mode for evaluating procedure arguments when it is not necessary. * Code structure simplification and cleanup. * Cleanup in .test files
2005-08-03 05:37:32 +02:00
routine= (Sroutine_hash_entry*)thd->lex->sroutines_list.first;
Added Non-prelocked SP execution: Now a PROCEDURE doesn't enter/leave prelocked mode for its body, but lets each statement to get/release its own locks. This allows a broader set of statements to be executed inside PROCEDUREs (but breaks replication) This patch should fix BUG#8072, BUG#8766, BUG#9563, BUG#11126
2005-07-30 10:19:57 +02:00
Prelocking-free SPs, post-review fixes: * Don't activate prelocking mode for evaluating procedure arguments when it is not necessary. * Code structure simplification and cleanup. * Cleanup in .test files
2005-08-03 05:37:32 +02:00
DBUG_ASSERT(routine);
bool first_is_procedure= (routine->key.str[0] == TYPE_ENUM_PROCEDURE);
Added Non-prelocked SP execution: Now a PROCEDURE doesn't enter/leave prelocked mode for its body, but lets each statement to get/release its own locks. This allows a broader set of statements to be executed inside PROCEDUREs (but breaks replication) This patch should fix BUG#8072, BUG#8766, BUG#9563, BUG#11126
2005-07-30 10:19:57 +02:00
Prelocking-free SPs, post-review fixes: * Don't activate prelocking mode for evaluating procedure arguments when it is not necessary. * Code structure simplification and cleanup. * Cleanup in .test files
2005-08-03 05:37:32 +02:00
*first_no_prelocking= first_is_procedure;
*need_prelocking= !first_is_procedure || test(routine->next);
Added Non-prelocked SP execution: Now a PROCEDURE doesn't enter/leave prelocked mode for its body, but lets each statement to get/release its own locks. This allows a broader set of statements to be executed inside PROCEDUREs (but breaks replication) This patch should fix BUG#8072, BUG#8766, BUG#9563, BUG#11126
2005-07-30 10:19:57 +02:00
}
Doxygenized comments.
2007-10-11 20:37:45 +02:00
/**
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
Auxilary function that adds new element to the set of stored routines
used by statement.
Doxygenized comments.
2007-10-11 20:37:45 +02:00
In case when statement uses stored routines but does not need
prelocking (i.e. it does not use any tables) we will access the
elements of LEX::sroutines set on prepared statement re-execution.
Because of this we have to allocate memory for both hash element
and copy of its key in persistent arena.
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
Doxygenized comments.
2007-10-11 20:37:45 +02:00
@param lex LEX representing statement
@param arena Arena in which memory for new element will be
allocated
@param key Key for the hash representing set
@param belong_to_view Uppermost view which uses this routine
(0 if routine is not used by view)
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
Doxygenized comments.
2007-10-11 20:37:45 +02:00
@note
Will also add element to end of 'LEX::sroutines_list' list.
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
Doxygenized comments.
2007-10-11 20:37:45 +02:00
@todo
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
When we will got rid of these accesses on re-executions we will be
able to allocate memory for hash elements in non-persitent arena
and directly use key values from sp_head::m_sroutines sets instead
of making their copies.
Doxygenized comments.
2007-10-11 20:37:45 +02:00
@retval
TRUE new element was added.
@retval
FALSE element was not added (because it is already present in
the set).
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
*/
Manual fixes after merging patch for bug #8406 "Triggers crash if referencing a table" with main tree.
2005-07-09 21:11:17 +02:00
static bool add_used_routine(LEX *lex, Query_arena *arena,
Fix for bug #11555 "Stored procedures: current SP tables locking make impossible view security". We should not expose names of tables which are explicitly or implicitly (via routine or trigger) used by view even if we find that they are missing. So during building of list of prelocked tables for statement we track which routines (and therefore tables for these routines) are used from views. We mark elements of LEX::routines set which correspond to routines used in views by setting Sroutine_hash_entry::belong_to_view member to point to TABLE_LIST object for topmost view which uses routine. We propagate this mark to all routines which are used by this routine and which we add to this set. We also mark tables used by such routine which we add to the list of tables for prelocking as belonging to this view.
2005-12-07 10:27:17 +01:00
const LEX_STRING *key,
TABLE_LIST *belong_to_view)
Made FUNCTIONs work in insert and select queries, as well as nested function invocations. Had to add a cahing mechanism which is in parts an ugly kludge, but it will be reworked once the real SP caching is implemented.
2003-03-02 19:17:41 +01:00
{
Small cleanup in code handling stored routines/table prelocking. Use lazy initialization for Query_tables_list::sroutines hash. This step should significantly decrease amount of memory consumed by stored routines as we no longer will allocate chunk of memory required for this HASH for each statement in routine.
2006-11-01 13:41:48 +01:00
hash_init_opt(&lex->sroutines, system_charset_info,
Query_tables_list::START_SROUTINES_HASH_SIZE,
0, 0, sp_sroutine_key, 0, 0);
WL#3817: Simplify string / memory area types and make things more consistent (first part) The following type conversions was done: - Changed byte to uchar - Changed gptr to uchar* - Change my_string to char * - Change my_size_t to size_t - Change size_s to size_t Removed declaration of byte, gptr, my_string, my_size_t and size_s. Following function parameter changes was done: - All string functions in mysys/strings was changed to use size_t instead of uint for string lengths. - All read()/write() functions changed to use size_t (including vio). - All protocoll functions changed to use size_t instead of uint - Functions that used a pointer to a string length was changed to use size_t* - Changed malloc(), free() and related functions from using gptr to use void * as this requires fewer casts in the code and is more in line with how the standard functions work. - Added extra length argument to dirname_part() to return the length of the created string. - Changed (at least) following functions to take uchar* as argument: - db_dump() - my_net_write() - net_write_command() - net_store_data() - DBUG_DUMP() - decimal2bin() & bin2decimal() - Changed my_compress() and my_uncompress() to use size_t. Changed one argument to my_uncompress() from a pointer to a value as we only return one value (makes function easier to use). - Changed type of 'pack_data' argument to packfrm() to avoid casts. - Changed in readfrm() and writefrom(), ha_discover and handler::discover() the type for argument 'frmdata' to uchar** to avoid casts. - Changed most Field functions to use uchar* instead of char* (reduced a lot of casts). - Changed field->val_xxx(xxx, new_ptr) to take const pointers. Other changes: - Removed a lot of not needed casts - Added a few new cast required by other changes - Added some cast to my_multi_malloc() arguments for safety (as string lengths needs to be uint, not size_t). - Fixed all calls to hash-get-key functions to use size_t*. (Needed to be done explicitely as this conflict was often hided by casting the function to hash_get_key). - Changed some buffers to memory regions to uchar* to avoid casts. - Changed some string lengths from uint to size_t. - Changed field->ptr to be uchar* instead of char*. This allowed us to get rid of a lot of casts. - Some changes from true -> TRUE, false -> FALSE, unsigned char -> uchar - Include zlib.h in some files as we needed declaration of crc32() - Changed MY_FILE_ERROR to be (size_t) -1. - Changed many variables to hold the result of my_read() / my_write() to be size_t. This was needed to properly detect errors (which are returned as (size_t) -1). - Removed some very old VMS code - Changed packfrm()/unpackfrm() to not be depending on uint size (portability fix) - Removed windows specific code to restore cursor position as this causes slowdown on windows and we should not mix read() and pread() calls anyway as this is not thread safe. Updated function comment to reflect this. Changed function that depended on original behavior of my_pwrite() to itself restore the cursor position (one such case). - Added some missing checking of return value of malloc(). - Changed definition of MOD_PAD_CHAR_TO_FULL_LENGTH to avoid 'long' overflow. - Changed type of table_def::m_size from my_size_t to ulong to reflect that m_size is the number of elements in the array, not a string/memory length. - Moved THD::max_row_length() to table.cc (as it's not depending on THD). Inlined max_row_length_blob() into this function. - More function comments - Fixed some compiler warnings when compiled without partitions. - Removed setting of LEX_STRING() arguments in declaration (portability fix). - Some trivial indentation/variable name changes. - Some trivial code simplifications: - Replaced some calls to alloc_root + memcpy to use strmake_root()/strdup_root(). - Changed some calls from memdup() to strmake() (Safety fix) - Simpler loops in client-simple.c
2007-05-10 11:59:39 +02:00
if (!hash_search(&lex->sroutines, (uchar *)key->str, key->length))
Made FUNCTIONs work in insert and select queries, as well as nested function invocations. Had to add a cahing mechanism which is in parts an ugly kludge, but it will be reworked once the real SP caching is implemented.
2003-03-02 19:17:41 +01:00
{
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
Sroutine_hash_entry *rn=
(Sroutine_hash_entry *)arena->alloc(sizeof(Sroutine_hash_entry) +
Bug#28318 CREATE FUNCTION (UDF) requires a schema Bug#29816 Syntactically wrong query fails with misleading error message The core problem is that an SQL-invoked function name can be a <schema qualified routine name> that contains no <schema name>, but the mysql parser insists that all stored procedures (function, procedures and triggers) must have a <schema name>, which is not true for functions. This problem is especially visible when trying to create a function or when a query contains a syntax error after a function call (in the same query), both will fail with a "No database selected" message if the session is not attached to a particular schema, but the first one should succeed and the second fail with a "syntax error" message. Part of the fix is to revamp the sp name handling so that a schema name may be omitted for functions -- this means that the internal function name representation may not have a dot, which represents that the function doesn't have a schema name. The other part is to place schema checks after the type (function, trigger or procedure) of the routine is known.
2007-10-10 01:46:33 +02:00
key->length + 1);
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
if (!rn) // OOM. Error will be reported using fatal_error().
return FALSE;
rn->key.length= key->length;
rn->key.str= (char *)rn + sizeof(Sroutine_hash_entry);
Bug#28318 CREATE FUNCTION (UDF) requires a schema Bug#29816 Syntactically wrong query fails with misleading error message The core problem is that an SQL-invoked function name can be a <schema qualified routine name> that contains no <schema name>, but the mysql parser insists that all stored procedures (function, procedures and triggers) must have a <schema name>, which is not true for functions. This problem is especially visible when trying to create a function or when a query contains a syntax error after a function call (in the same query), both will fail with a "No database selected" message if the session is not attached to a particular schema, but the first one should succeed and the second fail with a "syntax error" message. Part of the fix is to revamp the sp name handling so that a schema name may be omitted for functions -- this means that the internal function name representation may not have a dot, which represents that the function doesn't have a schema name. The other part is to place schema checks after the type (function, trigger or procedure) of the routine is known.
2007-10-10 01:46:33 +02:00
memcpy(rn->key.str, key->str, key->length + 1);
WL#3817: Simplify string / memory area types and make things more consistent (first part) The following type conversions was done: - Changed byte to uchar - Changed gptr to uchar* - Change my_string to char * - Change my_size_t to size_t - Change size_s to size_t Removed declaration of byte, gptr, my_string, my_size_t and size_s. Following function parameter changes was done: - All string functions in mysys/strings was changed to use size_t instead of uint for string lengths. - All read()/write() functions changed to use size_t (including vio). - All protocoll functions changed to use size_t instead of uint - Functions that used a pointer to a string length was changed to use size_t* - Changed malloc(), free() and related functions from using gptr to use void * as this requires fewer casts in the code and is more in line with how the standard functions work. - Added extra length argument to dirname_part() to return the length of the created string. - Changed (at least) following functions to take uchar* as argument: - db_dump() - my_net_write() - net_write_command() - net_store_data() - DBUG_DUMP() - decimal2bin() & bin2decimal() - Changed my_compress() and my_uncompress() to use size_t. Changed one argument to my_uncompress() from a pointer to a value as we only return one value (makes function easier to use). - Changed type of 'pack_data' argument to packfrm() to avoid casts. - Changed in readfrm() and writefrom(), ha_discover and handler::discover() the type for argument 'frmdata' to uchar** to avoid casts. - Changed most Field functions to use uchar* instead of char* (reduced a lot of casts). - Changed field->val_xxx(xxx, new_ptr) to take const pointers. Other changes: - Removed a lot of not needed casts - Added a few new cast required by other changes - Added some cast to my_multi_malloc() arguments for safety (as string lengths needs to be uint, not size_t). - Fixed all calls to hash-get-key functions to use size_t*. (Needed to be done explicitely as this conflict was often hided by casting the function to hash_get_key). - Changed some buffers to memory regions to uchar* to avoid casts. - Changed some string lengths from uint to size_t. - Changed field->ptr to be uchar* instead of char*. This allowed us to get rid of a lot of casts. - Some changes from true -> TRUE, false -> FALSE, unsigned char -> uchar - Include zlib.h in some files as we needed declaration of crc32() - Changed MY_FILE_ERROR to be (size_t) -1. - Changed many variables to hold the result of my_read() / my_write() to be size_t. This was needed to properly detect errors (which are returned as (size_t) -1). - Removed some very old VMS code - Changed packfrm()/unpackfrm() to not be depending on uint size (portability fix) - Removed windows specific code to restore cursor position as this causes slowdown on windows and we should not mix read() and pread() calls anyway as this is not thread safe. Updated function comment to reflect this. Changed function that depended on original behavior of my_pwrite() to itself restore the cursor position (one such case). - Added some missing checking of return value of malloc(). - Changed definition of MOD_PAD_CHAR_TO_FULL_LENGTH to avoid 'long' overflow. - Changed type of table_def::m_size from my_size_t to ulong to reflect that m_size is the number of elements in the array, not a string/memory length. - Moved THD::max_row_length() to table.cc (as it's not depending on THD). Inlined max_row_length_blob() into this function. - More function comments - Fixed some compiler warnings when compiled without partitions. - Removed setting of LEX_STRING() arguments in declaration (portability fix). - Some trivial indentation/variable name changes. - Some trivial code simplifications: - Replaced some calls to alloc_root + memcpy to use strmake_root()/strdup_root(). - Changed some calls from memdup() to strmake() (Safety fix) - Simpler loops in client-simple.c
2007-05-10 11:59:39 +02:00
my_hash_insert(&lex->sroutines, (uchar *)rn);
lex->sroutines_list.link_in_list((uchar *)rn, (uchar **)&rn->next);
Fix for bug #11555 "Stored procedures: current SP tables locking make impossible view security". We should not expose names of tables which are explicitly or implicitly (via routine or trigger) used by view even if we find that they are missing. So during building of list of prelocked tables for statement we track which routines (and therefore tables for these routines) are used from views. We mark elements of LEX::routines set which correspond to routines used in views by setting Sroutine_hash_entry::belong_to_view member to point to TABLE_LIST object for topmost view which uses routine. We propagate this mark to all routines which are used by this routine and which we add to this set. We also mark tables used by such routine which we add to the list of tables for prelocking as belonging to this view.
2005-12-07 10:27:17 +01:00
rn->belong_to_view= belong_to_view;
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
return TRUE;
Made FUNCTIONs work in insert and select queries, as well as nested function invocations. Had to add a cahing mechanism which is in parts an ugly kludge, but it will be reworked once the real SP caching is implemented.
2003-03-02 19:17:41 +01:00
}
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
return FALSE;
Made FUNCTIONs work in insert and select queries, as well as nested function invocations. Had to add a cahing mechanism which is in parts an ugly kludge, but it will be reworked once the real SP caching is implemented.
2003-03-02 19:17:41 +01:00
}
Fixed memory leaks in SP Some code cleanup
2003-12-21 11:48:03 +01:00
Doxygenized comments.
2007-10-11 20:37:45 +02:00
/**
Fix for bug #12704 "Server crashes during trigger execution". This bug occurs when some trigger for table used by DML statement is created or changed while statement was waiting in lock_tables(). In this situation prelocking set which we have calculated becames invalid which can easily lead to errors and even in some cases to crashes. With proposed patch we no longer silently reopen tables in lock_tables(), instead caller of lock_tables() becomes responsible for reopening tables and recalculation of prelocking set.
2005-09-15 01:56:09 +02:00
Add routine which is explicitly used by statement to the set of stored
routines used by this statement.
Better approach for prelocking of tables for stored routines execution and some SP-related cleanups. - We don't have separate stage for calculation of list of tables to be prelocked and doing implicit LOCK/UNLOCK any more. Instead we calculate this list at open_tables() and do implicit LOCK in lock_tables() (and UNLOCK in close_thread_tables()). Also now we support cases when same table (with same alias) is used several times in the same query in SP. - Cleaned up execution of SP. Moved all common code which handles LEX and does preparations before statement execution or complex expression evaluation to auxilary sp_lex_keeper class. Now all statements in SP (and corresponding instructions) that evaluate expression which can contain subquery have their own LEX.
2005-03-04 14:35:28 +01:00
Doxygenized comments.
2007-10-11 20:37:45 +02:00
To be friendly towards prepared statements one should pass
persistent arena as second argument.
@param lex LEX representing statement
@param arena arena in which memory for new element of the set
will be allocated
@param rt routine name
@param rt_type routine type (one of TYPE_ENUM_PROCEDURE/...)
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
Doxygenized comments.
2007-10-11 20:37:45 +02:00
@note
Fix for bug #12704 "Server crashes during trigger execution". This bug occurs when some trigger for table used by DML statement is created or changed while statement was waiting in lock_tables(). In this situation prelocking set which we have calculated becames invalid which can easily lead to errors and even in some cases to crashes. With proposed patch we no longer silently reopen tables in lock_tables(), instead caller of lock_tables() becomes responsible for reopening tables and recalculation of prelocking set.
2005-09-15 01:56:09 +02:00
Will also add element to end of 'LEX::sroutines_list' list (and will
take into account that this is explicitly used routine).
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
*/
Manual fixes after merging patch for bug #8406 "Triggers crash if referencing a table" with main tree.
2005-07-09 21:11:17 +02:00
void sp_add_used_routine(LEX *lex, Query_arena *arena,
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
sp_name *rt, char rt_type)
{
rt->set_routine_type(rt_type);
Fix for bug #11555 "Stored procedures: current SP tables locking make impossible view security". We should not expose names of tables which are explicitly or implicitly (via routine or trigger) used by view even if we find that they are missing. So during building of list of prelocked tables for statement we track which routines (and therefore tables for these routines) are used from views. We mark elements of LEX::routines set which correspond to routines used in views by setting Sroutine_hash_entry::belong_to_view member to point to TABLE_LIST object for topmost view which uses routine. We propagate this mark to all routines which are used by this routine and which we add to this set. We also mark tables used by such routine which we add to the list of tables for prelocking as belonging to this view.
2005-12-07 10:27:17 +01:00
(void)add_used_routine(lex, arena, &rt->m_sroutines_key, 0);
Fix for bug #12704 "Server crashes during trigger execution". This bug occurs when some trigger for table used by DML statement is created or changed while statement was waiting in lock_tables(). In this situation prelocking set which we have calculated becames invalid which can easily lead to errors and even in some cases to crashes. With proposed patch we no longer silently reopen tables in lock_tables(), instead caller of lock_tables() becomes responsible for reopening tables and recalculation of prelocking set.
2005-09-15 01:56:09 +02:00
lex->sroutines_list_own_last= lex->sroutines_list.next;
lex->sroutines_list_own_elements= lex->sroutines_list.elements;
}
Doxygenized comments.
2007-10-11 20:37:45 +02:00
/**
Fix for bug #12704 "Server crashes during trigger execution". This bug occurs when some trigger for table used by DML statement is created or changed while statement was waiting in lock_tables(). In this situation prelocking set which we have calculated becames invalid which can easily lead to errors and even in some cases to crashes. With proposed patch we no longer silently reopen tables in lock_tables(), instead caller of lock_tables() becomes responsible for reopening tables and recalculation of prelocking set.
2005-09-15 01:56:09 +02:00
Remove routines which are only indirectly used by statement from
the set of routines used by this statement.
Doxygenized comments.
2007-10-11 20:37:45 +02:00
@param lex LEX representing statement
Fix for bug #12704 "Server crashes during trigger execution". This bug occurs when some trigger for table used by DML statement is created or changed while statement was waiting in lock_tables(). In this situation prelocking set which we have calculated becames invalid which can easily lead to errors and even in some cases to crashes. With proposed patch we no longer silently reopen tables in lock_tables(), instead caller of lock_tables() becomes responsible for reopening tables and recalculation of prelocking set.
2005-09-15 01:56:09 +02:00
*/
void sp_remove_not_own_routines(LEX *lex)
{
Sroutine_hash_entry *not_own_rt, *next_rt;
for (not_own_rt= *(Sroutine_hash_entry **)lex->sroutines_list_own_last;
not_own_rt; not_own_rt= next_rt)
{
/*
It is safe to obtain not_own_rt->next after calling hash_delete() now
but we want to be more future-proof.
*/
next_rt= not_own_rt->next;
WL#3817: Simplify string / memory area types and make things more consistent (first part) The following type conversions was done: - Changed byte to uchar - Changed gptr to uchar* - Change my_string to char * - Change my_size_t to size_t - Change size_s to size_t Removed declaration of byte, gptr, my_string, my_size_t and size_s. Following function parameter changes was done: - All string functions in mysys/strings was changed to use size_t instead of uint for string lengths. - All read()/write() functions changed to use size_t (including vio). - All protocoll functions changed to use size_t instead of uint - Functions that used a pointer to a string length was changed to use size_t* - Changed malloc(), free() and related functions from using gptr to use void * as this requires fewer casts in the code and is more in line with how the standard functions work. - Added extra length argument to dirname_part() to return the length of the created string. - Changed (at least) following functions to take uchar* as argument: - db_dump() - my_net_write() - net_write_command() - net_store_data() - DBUG_DUMP() - decimal2bin() & bin2decimal() - Changed my_compress() and my_uncompress() to use size_t. Changed one argument to my_uncompress() from a pointer to a value as we only return one value (makes function easier to use). - Changed type of 'pack_data' argument to packfrm() to avoid casts. - Changed in readfrm() and writefrom(), ha_discover and handler::discover() the type for argument 'frmdata' to uchar** to avoid casts. - Changed most Field functions to use uchar* instead of char* (reduced a lot of casts). - Changed field->val_xxx(xxx, new_ptr) to take const pointers. Other changes: - Removed a lot of not needed casts - Added a few new cast required by other changes - Added some cast to my_multi_malloc() arguments for safety (as string lengths needs to be uint, not size_t). - Fixed all calls to hash-get-key functions to use size_t*. (Needed to be done explicitely as this conflict was often hided by casting the function to hash_get_key). - Changed some buffers to memory regions to uchar* to avoid casts. - Changed some string lengths from uint to size_t. - Changed field->ptr to be uchar* instead of char*. This allowed us to get rid of a lot of casts. - Some changes from true -> TRUE, false -> FALSE, unsigned char -> uchar - Include zlib.h in some files as we needed declaration of crc32() - Changed MY_FILE_ERROR to be (size_t) -1. - Changed many variables to hold the result of my_read() / my_write() to be size_t. This was needed to properly detect errors (which are returned as (size_t) -1). - Removed some very old VMS code - Changed packfrm()/unpackfrm() to not be depending on uint size (portability fix) - Removed windows specific code to restore cursor position as this causes slowdown on windows and we should not mix read() and pread() calls anyway as this is not thread safe. Updated function comment to reflect this. Changed function that depended on original behavior of my_pwrite() to itself restore the cursor position (one such case). - Added some missing checking of return value of malloc(). - Changed definition of MOD_PAD_CHAR_TO_FULL_LENGTH to avoid 'long' overflow. - Changed type of table_def::m_size from my_size_t to ulong to reflect that m_size is the number of elements in the array, not a string/memory length. - Moved THD::max_row_length() to table.cc (as it's not depending on THD). Inlined max_row_length_blob() into this function. - More function comments - Fixed some compiler warnings when compiled without partitions. - Removed setting of LEX_STRING() arguments in declaration (portability fix). - Some trivial indentation/variable name changes. - Some trivial code simplifications: - Replaced some calls to alloc_root + memcpy to use strmake_root()/strdup_root(). - Changed some calls from memdup() to strmake() (Safety fix) - Simpler loops in client-simple.c
2007-05-10 11:59:39 +02:00
hash_delete(&lex->sroutines, (uchar *)not_own_rt);
Fix for bug #12704 "Server crashes during trigger execution". This bug occurs when some trigger for table used by DML statement is created or changed while statement was waiting in lock_tables(). In this situation prelocking set which we have calculated becames invalid which can easily lead to errors and even in some cases to crashes. With proposed patch we no longer silently reopen tables in lock_tables(), instead caller of lock_tables() becomes responsible for reopening tables and recalculation of prelocking set.
2005-09-15 01:56:09 +02:00
}
*(Sroutine_hash_entry **)lex->sroutines_list_own_last= NULL;
lex->sroutines_list.next= lex->sroutines_list_own_last;
lex->sroutines_list.elements= lex->sroutines_list_own_elements;
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
}
Doxygenized comments.
2007-10-11 20:37:45 +02:00
/**
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
Merge contents of two hashes representing sets of routines used
by statements or by other routines.
Doxygenized comments.
2007-10-11 20:37:45 +02:00
@param dst hash to which elements should be added
@param src hash from which elements merged
Better approach for prelocking of tables for stored routines execution and some SP-related cleanups. - We don't have separate stage for calculation of list of tables to be prelocked and doing implicit LOCK/UNLOCK any more. Instead we calculate this list at open_tables() and do implicit LOCK in lock_tables() (and UNLOCK in close_thread_tables()). Also now we support cases when same table (with same alias) is used several times in the same query in SP. - Cleaned up execution of SP. Moved all common code which handles LEX and does preparations before statement execution or complex expression evaluation to auxilary sp_lex_keeper class. Now all statements in SP (and corresponding instructions) that evaluate expression which can contain subquery have their own LEX.
2005-03-04 14:35:28 +01:00
Doxygenized comments.
2007-10-11 20:37:45 +02:00
@note
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
This procedure won't create new Sroutine_hash_entry objects,
instead it will simply add elements from source to destination
hash. Thus time of life of elements in destination hash becomes
dependant on time of life of elements from source hash. It also
won't touch lists linking elements in source and destination
hashes.
Better approach for prelocking of tables for stored routines execution and some SP-related cleanups. - We don't have separate stage for calculation of list of tables to be prelocked and doing implicit LOCK/UNLOCK any more. Instead we calculate this list at open_tables() and do implicit LOCK in lock_tables() (and UNLOCK in close_thread_tables()). Also now we support cases when same table (with same alias) is used several times in the same query in SP. - Cleaned up execution of SP. Moved all common code which handles LEX and does preparations before statement execution or complex expression evaluation to auxilary sp_lex_keeper class. Now all statements in SP (and corresponding instructions) that evaluate expression which can contain subquery have their own LEX.
2005-03-04 14:35:28 +01:00
*/
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
void sp_update_sp_used_routines(HASH *dst, HASH *src)
Made FUNCTIONs work in insert and select queries, as well as nested function invocations. Had to add a cahing mechanism which is in parts an ugly kludge, but it will be reworked once the real SP caching is implemented.
2003-03-02 19:17:41 +01:00
{
WL#2130: Table locking for stored FUNCTIONs Collect all tables and SPs refered by a statement, and open all tables with an implicit LOCK TABLES. Do find things refered by triggers and views, we open them first (and then repeat this until nothing new is found), before doing the actual lock tables.
2005-02-08 20:52:50 +01:00
for (uint i=0 ; i < src->records ; i++)
Made FUNCTIONs work in insert and select queries, as well as nested function invocations. Had to add a cahing mechanism which is in parts an ugly kludge, but it will be reworked once the real SP caching is implemented.
2003-03-02 19:17:41 +01:00
{
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
Sroutine_hash_entry *rt= (Sroutine_hash_entry *)hash_element(src, i);
WL#3817: Simplify string / memory area types and make things more consistent (first part) The following type conversions was done: - Changed byte to uchar - Changed gptr to uchar* - Change my_string to char * - Change my_size_t to size_t - Change size_s to size_t Removed declaration of byte, gptr, my_string, my_size_t and size_s. Following function parameter changes was done: - All string functions in mysys/strings was changed to use size_t instead of uint for string lengths. - All read()/write() functions changed to use size_t (including vio). - All protocoll functions changed to use size_t instead of uint - Functions that used a pointer to a string length was changed to use size_t* - Changed malloc(), free() and related functions from using gptr to use void * as this requires fewer casts in the code and is more in line with how the standard functions work. - Added extra length argument to dirname_part() to return the length of the created string. - Changed (at least) following functions to take uchar* as argument: - db_dump() - my_net_write() - net_write_command() - net_store_data() - DBUG_DUMP() - decimal2bin() & bin2decimal() - Changed my_compress() and my_uncompress() to use size_t. Changed one argument to my_uncompress() from a pointer to a value as we only return one value (makes function easier to use). - Changed type of 'pack_data' argument to packfrm() to avoid casts. - Changed in readfrm() and writefrom(), ha_discover and handler::discover() the type for argument 'frmdata' to uchar** to avoid casts. - Changed most Field functions to use uchar* instead of char* (reduced a lot of casts). - Changed field->val_xxx(xxx, new_ptr) to take const pointers. Other changes: - Removed a lot of not needed casts - Added a few new cast required by other changes - Added some cast to my_multi_malloc() arguments for safety (as string lengths needs to be uint, not size_t). - Fixed all calls to hash-get-key functions to use size_t*. (Needed to be done explicitely as this conflict was often hided by casting the function to hash_get_key). - Changed some buffers to memory regions to uchar* to avoid casts. - Changed some string lengths from uint to size_t. - Changed field->ptr to be uchar* instead of char*. This allowed us to get rid of a lot of casts. - Some changes from true -> TRUE, false -> FALSE, unsigned char -> uchar - Include zlib.h in some files as we needed declaration of crc32() - Changed MY_FILE_ERROR to be (size_t) -1. - Changed many variables to hold the result of my_read() / my_write() to be size_t. This was needed to properly detect errors (which are returned as (size_t) -1). - Removed some very old VMS code - Changed packfrm()/unpackfrm() to not be depending on uint size (portability fix) - Removed windows specific code to restore cursor position as this causes slowdown on windows and we should not mix read() and pread() calls anyway as this is not thread safe. Updated function comment to reflect this. Changed function that depended on original behavior of my_pwrite() to itself restore the cursor position (one such case). - Added some missing checking of return value of malloc(). - Changed definition of MOD_PAD_CHAR_TO_FULL_LENGTH to avoid 'long' overflow. - Changed type of table_def::m_size from my_size_t to ulong to reflect that m_size is the number of elements in the array, not a string/memory length. - Moved THD::max_row_length() to table.cc (as it's not depending on THD). Inlined max_row_length_blob() into this function. - More function comments - Fixed some compiler warnings when compiled without partitions. - Removed setting of LEX_STRING() arguments in declaration (portability fix). - Some trivial indentation/variable name changes. - Some trivial code simplifications: - Replaced some calls to alloc_root + memcpy to use strmake_root()/strdup_root(). - Changed some calls from memdup() to strmake() (Safety fix) - Simpler loops in client-simple.c
2007-05-10 11:59:39 +02:00
if (!hash_search(dst, (uchar *)rt->key.str, rt->key.length))
my_hash_insert(dst, (uchar *)rt);
Made FUNCTIONs work in insert and select queries, as well as nested function invocations. Had to add a cahing mechanism which is in parts an ugly kludge, but it will be reworked once the real SP caching is implemented.
2003-03-02 19:17:41 +01:00
}
}
Fixed memory leaks in SP Some code cleanup
2003-12-21 11:48:03 +01:00
Doxygenized comments.
2007-10-11 20:37:45 +02:00
/**
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
Add contents of hash representing set of routines to the set of
routines used by statement.
Better approach for prelocking of tables for stored routines execution and some SP-related cleanups. - We don't have separate stage for calculation of list of tables to be prelocked and doing implicit LOCK/UNLOCK any more. Instead we calculate this list at open_tables() and do implicit LOCK in lock_tables() (and UNLOCK in close_thread_tables()). Also now we support cases when same table (with same alias) is used several times in the same query in SP. - Cleaned up execution of SP. Moved all common code which handles LEX and does preparations before statement execution or complex expression evaluation to auxilary sp_lex_keeper class. Now all statements in SP (and corresponding instructions) that evaluate expression which can contain subquery have their own LEX.
2005-03-04 14:35:28 +01:00
Doxygenized comments.
2007-10-11 20:37:45 +02:00
@param thd Thread context
@param lex LEX representing statement
@param src Hash representing set from which routines will
be added
@param belong_to_view Uppermost view which uses these routines, 0 if none
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
Doxygenized comments.
2007-10-11 20:37:45 +02:00
@note
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
It will also add elements to end of 'LEX::sroutines_list' list.
*/
Fix for bug #11555 "Stored procedures: current SP tables locking make impossible view security". We should not expose names of tables which are explicitly or implicitly (via routine or trigger) used by view even if we find that they are missing. So during building of list of prelocked tables for statement we track which routines (and therefore tables for these routines) are used from views. We mark elements of LEX::routines set which correspond to routines used in views by setting Sroutine_hash_entry::belong_to_view member to point to TABLE_LIST object for topmost view which uses routine. We propagate this mark to all routines which are used by this routine and which we add to this set. We also mark tables used by such routine which we add to the list of tables for prelocking as belonging to this view.
2005-12-07 10:27:17 +01:00
static void
sp_update_stmt_used_routines(THD *thd, LEX *lex, HASH *src,
TABLE_LIST *belong_to_view)
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
{
for (uint i=0 ; i < src->records ; i++)
{
Sroutine_hash_entry *rt= (Sroutine_hash_entry *)hash_element(src, i);
Fix for bug #11555 "Stored procedures: current SP tables locking make impossible view security". We should not expose names of tables which are explicitly or implicitly (via routine or trigger) used by view even if we find that they are missing. So during building of list of prelocked tables for statement we track which routines (and therefore tables for these routines) are used from views. We mark elements of LEX::routines set which correspond to routines used in views by setting Sroutine_hash_entry::belong_to_view member to point to TABLE_LIST object for topmost view which uses routine. We propagate this mark to all routines which are used by this routine and which we add to this set. We also mark tables used by such routine which we add to the list of tables for prelocking as belonging to this view.
2005-12-07 10:27:17 +01:00
(void)add_used_routine(lex, thd->stmt_arena, &rt->key, belong_to_view);
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
}
}
Doxygenized comments.
2007-10-11 20:37:45 +02:00
/**
Fix for bug #12704 "Server crashes during trigger execution". This bug occurs when some trigger for table used by DML statement is created or changed while statement was waiting in lock_tables(). In this situation prelocking set which we have calculated becames invalid which can easily lead to errors and even in some cases to crashes. With proposed patch we no longer silently reopen tables in lock_tables(), instead caller of lock_tables() becomes responsible for reopening tables and recalculation of prelocking set.
2005-09-15 01:56:09 +02:00
Add contents of list representing set of routines to the set of
routines used by statement.
Doxygenized comments.
2007-10-11 20:37:45 +02:00
@param thd Thread context
@param lex LEX representing statement
@param src List representing set from which routines will
be added
@param belong_to_view Uppermost view which uses these routines, 0 if none
Fix for bug #12704 "Server crashes during trigger execution". This bug occurs when some trigger for table used by DML statement is created or changed while statement was waiting in lock_tables(). In this situation prelocking set which we have calculated becames invalid which can easily lead to errors and even in some cases to crashes. With proposed patch we no longer silently reopen tables in lock_tables(), instead caller of lock_tables() becomes responsible for reopening tables and recalculation of prelocking set.
2005-09-15 01:56:09 +02:00
Doxygenized comments.
2007-10-11 20:37:45 +02:00
@note
Fix for bug #12704 "Server crashes during trigger execution". This bug occurs when some trigger for table used by DML statement is created or changed while statement was waiting in lock_tables(). In this situation prelocking set which we have calculated becames invalid which can easily lead to errors and even in some cases to crashes. With proposed patch we no longer silently reopen tables in lock_tables(), instead caller of lock_tables() becomes responsible for reopening tables and recalculation of prelocking set.
2005-09-15 01:56:09 +02:00
It will also add elements to end of 'LEX::sroutines_list' list.
*/
Fix for bug #11555 "Stored procedures: current SP tables locking make impossible view security". We should not expose names of tables which are explicitly or implicitly (via routine or trigger) used by view even if we find that they are missing. So during building of list of prelocked tables for statement we track which routines (and therefore tables for these routines) are used from views. We mark elements of LEX::routines set which correspond to routines used in views by setting Sroutine_hash_entry::belong_to_view member to point to TABLE_LIST object for topmost view which uses routine. We propagate this mark to all routines which are used by this routine and which we add to this set. We also mark tables used by such routine which we add to the list of tables for prelocking as belonging to this view.
2005-12-07 10:27:17 +01:00
static void sp_update_stmt_used_routines(THD *thd, LEX *lex, SQL_LIST *src,
TABLE_LIST *belong_to_view)
Fix for bug #12704 "Server crashes during trigger execution". This bug occurs when some trigger for table used by DML statement is created or changed while statement was waiting in lock_tables(). In this situation prelocking set which we have calculated becames invalid which can easily lead to errors and even in some cases to crashes. With proposed patch we no longer silently reopen tables in lock_tables(), instead caller of lock_tables() becomes responsible for reopening tables and recalculation of prelocking set.
2005-09-15 01:56:09 +02:00
{
for (Sroutine_hash_entry *rt= (Sroutine_hash_entry *)src->first;
rt; rt= rt->next)
Fix for bug #11555 "Stored procedures: current SP tables locking make impossible view security". We should not expose names of tables which are explicitly or implicitly (via routine or trigger) used by view even if we find that they are missing. So during building of list of prelocked tables for statement we track which routines (and therefore tables for these routines) are used from views. We mark elements of LEX::routines set which correspond to routines used in views by setting Sroutine_hash_entry::belong_to_view member to point to TABLE_LIST object for topmost view which uses routine. We propagate this mark to all routines which are used by this routine and which we add to this set. We also mark tables used by such routine which we add to the list of tables for prelocking as belonging to this view.
2005-12-07 10:27:17 +01:00
(void)add_used_routine(lex, thd->stmt_arena, &rt->key, belong_to_view);
Fix for bug #12704 "Server crashes during trigger execution". This bug occurs when some trigger for table used by DML statement is created or changed while statement was waiting in lock_tables(). In this situation prelocking set which we have calculated becames invalid which can easily lead to errors and even in some cases to crashes. With proposed patch we no longer silently reopen tables in lock_tables(), instead caller of lock_tables() becomes responsible for reopening tables and recalculation of prelocking set.
2005-09-15 01:56:09 +02:00
}
Doxygenized comments.
2007-10-11 20:37:45 +02:00
/**
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
Cache sub-set of routines used by statement, add tables used by these
routines to statement table list. Do the same for all routines used
by these routines.
Doxygenized comments.
2007-10-11 20:37:45 +02:00
@param thd thread context
@param lex LEX representing statement
@param start first routine from the list of routines to be cached
(this list defines mentioned sub-set).
@param first_no_prelock If true, don't add tables or cache routines used by
the body of the first routine (i.e. *start)
will be executed in non-prelocked mode.
@param tabs_changed Set to TRUE some tables were added, FALSE otherwise
@note
Better approach for prelocking of tables for stored routines execution and some SP-related cleanups. - We don't have separate stage for calculation of list of tables to be prelocked and doing implicit LOCK/UNLOCK any more. Instead we calculate this list at open_tables() and do implicit LOCK in lock_tables() (and UNLOCK in close_thread_tables()). Also now we support cases when same table (with same alias) is used several times in the same query in SP. - Cleaned up execution of SP. Moved all common code which handles LEX and does preparations before statement execution or complex expression evaluation to auxilary sp_lex_keeper class. Now all statements in SP (and corresponding instructions) that evaluate expression which can contain subquery have their own LEX.
2005-03-04 14:35:28 +01:00
If some function is missing this won't be reported here.
Instead this fact will be discovered during query execution.
Doxygenized comments.
2007-10-11 20:37:45 +02:00
@retval
0 success
@retval
non-0 failure
Better approach for prelocking of tables for stored routines execution and some SP-related cleanups. - We don't have separate stage for calculation of list of tables to be prelocked and doing implicit LOCK/UNLOCK any more. Instead we calculate this list at open_tables() and do implicit LOCK in lock_tables() (and UNLOCK in close_thread_tables()). Also now we support cases when same table (with same alias) is used several times in the same query in SP. - Cleaned up execution of SP. Moved all common code which handles LEX and does preparations before statement execution or complex expression evaluation to auxilary sp_lex_keeper class. Now all statements in SP (and corresponding instructions) that evaluate expression which can contain subquery have their own LEX.
2005-03-04 14:35:28 +01:00
*/
Fixed BUG#14233: Crash after tampering with the mysql.proc table Added error checking for errors when attempting to use stored procedures after the mysql.proc table has been dropped, corrupted, or tampered with. Test cases were put in a separate file (sp-destruct.test).
2005-10-26 15:34:57 +02:00
static int
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
sp_cache_routines_and_add_tables_aux(THD *thd, LEX *lex,
Added Non-prelocked SP execution: Now a PROCEDURE doesn't enter/leave prelocked mode for its body, but lets each statement to get/release its own locks. This allows a broader set of statements to be executed inside PROCEDUREs (but breaks replication) This patch should fix BUG#8072, BUG#8766, BUG#9563, BUG#11126
2005-07-30 10:19:57 +02:00
Sroutine_hash_entry *start,
Bug#21039 Transaction cache not flushed after SELECT CREATE - Add prelocking for stored procedures that uses sp or sf - Update test result for sp_error(reported as bug#21294) - Make note about new error message from sp-error(bug#17244)
2006-07-26 12:40:26 +02:00
bool first_no_prelock)
Made FUNCTIONs work in insert and select queries, as well as nested function invocations. Had to add a cahing mechanism which is in parts an ugly kludge, but it will be reworked once the real SP caching is implemented.
2003-03-02 19:17:41 +01:00
{
Fixed BUG#14233: Crash after tampering with the mysql.proc table Added error checking for errors when attempting to use stored procedures after the mysql.proc table has been dropped, corrupted, or tampered with. Test cases were put in a separate file (sp-destruct.test).
2005-10-26 15:34:57 +02:00
int ret= 0;
Added Non-prelocked SP execution: Now a PROCEDURE doesn't enter/leave prelocked mode for its body, but lets each statement to get/release its own locks. This allows a broader set of statements to be executed inside PROCEDUREs (but breaks replication) This patch should fix BUG#8072, BUG#8766, BUG#9563, BUG#11126
2005-07-30 10:19:57 +02:00
bool first= TRUE;
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
DBUG_ENTER("sp_cache_routines_and_add_tables_aux");
Made FUNCTIONs work in insert and select queries, as well as nested function invocations. Had to add a cahing mechanism which is in parts an ugly kludge, but it will be reworked once the real SP caching is implemented.
2003-03-02 19:17:41 +01:00
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
for (Sroutine_hash_entry *rt= start; rt; rt= rt->next)
Made FUNCTIONs work in insert and select queries, as well as nested function invocations. Had to add a cahing mechanism which is in parts an ugly kludge, but it will be reworked once the real SP caching is implemented.
2003-03-02 19:17:41 +01:00
{
Bug#28318 CREATE FUNCTION (UDF) requires a schema Bug#29816 Syntactically wrong query fails with misleading error message The core problem is that an SQL-invoked function name can be a <schema qualified routine name> that contains no <schema name>, but the mysql parser insists that all stored procedures (function, procedures and triggers) must have a <schema name>, which is not true for functions. This problem is especially visible when trying to create a function or when a query contains a syntax error after a function call (in the same query), both will fail with a "No database selected" message if the session is not attached to a particular schema, but the first one should succeed and the second fail with a "syntax error" message. Part of the fix is to revamp the sp name handling so that a schema name may be omitted for functions -- this means that the internal function name representation may not have a dot, which represents that the function doesn't have a schema name. The other part is to place schema checks after the type (function, trigger or procedure) of the routine is known.
2007-10-10 01:46:33 +02:00
sp_name name(thd, rt->key.str, rt->key.length);
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
int type= rt->key.str[0];
sp_head *sp;
SP cache (WL#730). (Mostly by vva, additions by pem.)
2003-07-01 18:14:24 +02:00
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
if (!(sp= sp_cache_lookup((type == TYPE_ENUM_FUNCTION ?
&thd->sp_func_cache : &thd->sp_proc_cache),
&name)))
Made FUNCTIONs work in insert and select queries, as well as nested function invocations. Had to add a cahing mechanism which is in parts an ugly kludge, but it will be reworked once the real SP caching is implemented.
2003-03-02 19:17:41 +01:00
{
Fixed BUG#14233: Crash after tampering with the mysql.proc table Added error checking for errors when attempting to use stored procedures after the mysql.proc table has been dropped, corrupted, or tampered with. Test cases were put in a separate file (sp-destruct.test).
2005-10-26 15:34:57 +02:00
switch ((ret= db_find_routine(thd, type, &name, &sp)))
Fixed the old kludge for pre-loading functions and made it more efficient using a hash table instead (and made it work with lex pointers). Some additional code cleanup too.
2003-07-07 14:55:10 +02:00
{
Fixed BUG#14233: Crash after tampering with the mysql.proc table Added error checking for errors when attempting to use stored procedures after the mysql.proc table has been dropped, corrupted, or tampered with. Test cases were put in a separate file (sp-destruct.test).
2005-10-26 15:34:57 +02:00
case SP_OK:
{
if (type == TYPE_ENUM_FUNCTION)
sp_cache_insert(&thd->sp_func_cache, sp);
else
sp_cache_insert(&thd->sp_proc_cache, sp);
}
break;
case SP_KEY_NOT_FOUND:
ret= SP_OK;
break;
default:
/*
Fixed BUG#14233: Crash after tampering with the mysql.proc table Post-review version. Some minor review fixes, but also changed the way some errors are handled: Don't return specific parse errors; instead always use the more general "table corrupt" error (amended accordingly).
2005-11-25 17:09:26 +01:00
Any error when loading an existing routine is either some problem
with the mysql.proc table, or a parse error because the contents
has been tampered with (in which case we clear that error).
*/
if (ret == SP_PARSE_ERROR)
thd->clear_error();
Final review fix of #14233: Crash after tampering with the mysql.proc table. Changed variable type and added comment in sp.c.
2005-12-06 14:25:12 +01:00
/*
If we cleared the parse error, or when db_find_routine() flagged
an error with it's return value without calling my_error(), we
set the generic "mysql.proc table corrupt" error here.
*/
Use an inline getter method (thd->is_error()) to query if there is an error in THD. In future the error may be stored elsewhere (not in net.report_error) and it's important to start using an opaque getter to simplify merges.
2007-10-30 18:08:16 +01:00
if (! thd->is_error())
Fixed BUG#14233: Crash after tampering with the mysql.proc table Post-review version. Some minor review fixes, but also changed the way some errors are handled: Don't return specific parse errors; instead always use the more general "table corrupt" error (amended accordingly).
2005-11-25 17:09:26 +01:00
{
Fix for bug#21311: Possible stack overrun if SP has non-latin1 name There was possible stack overrun in an edge case which handles invalid body of a SP in mysql.proc . That should be case when mysql.proc has been changed manually. Though, due to bug 21513, it can be exploited without having access to mysql.proc only being able to create a stored routine.
2006-09-27 21:23:17 +02:00
/*
SP allows full NAME_LEN chars thus he have to allocate enough
size in bytes. Otherwise there is stack overrun could happen
if multibyte sequence is `name`. `db` is still safe because the
rest of the server checks agains NAME_LEN bytes and not chars.
Hence, the overrun happens only if the name is in length > 32 and
uses multibyte (cyrillic, greek, etc.)
*/
Bug#21432 Database/Table name limited to 64 bytes, not chars, problems with multi-byte
2007-04-03 13:13:27 +02:00
char n[NAME_LEN*2+2];
Fixed BUG#14233: Crash after tampering with the mysql.proc table Post-review version. Some minor review fixes, but also changed the way some errors are handled: Don't return specific parse errors; instead always use the more general "table corrupt" error (amended accordingly).
2005-11-25 17:09:26 +01:00
/* m_qname.str is not always \0 terminated */
memcpy(n, name.m_qname.str, name.m_qname.length);
n[name.m_qname.length]= '\0';
my_error(ER_SP_PROC_TABLE_CORRUPT, MYF(0), n, ret);
}
Fixed BUG#14233: Crash after tampering with the mysql.proc table Added error checking for errors when attempting to use stored procedures after the mysql.proc table has been dropped, corrupted, or tampered with. Test cases were put in a separate file (sp-destruct.test).
2005-10-26 15:34:57 +02:00
break;
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
}
}
if (sp)
{
Added Non-prelocked SP execution: Now a PROCEDURE doesn't enter/leave prelocked mode for its body, but lets each statement to get/release its own locks. This allows a broader set of statements to be executed inside PROCEDUREs (but breaks replication) This patch should fix BUG#8072, BUG#8766, BUG#9563, BUG#11126
2005-07-30 10:19:57 +02:00
if (!(first && first_no_prelock))
{
Fix for bug #11555 "Stored procedures: current SP tables locking make impossible view security". We should not expose names of tables which are explicitly or implicitly (via routine or trigger) used by view even if we find that they are missing. So during building of list of prelocked tables for statement we track which routines (and therefore tables for these routines) are used from views. We mark elements of LEX::routines set which correspond to routines used in views by setting Sroutine_hash_entry::belong_to_view member to point to TABLE_LIST object for topmost view which uses routine. We propagate this mark to all routines which are used by this routine and which we add to this set. We also mark tables used by such routine which we add to the list of tables for prelocking as belonging to this view.
2005-12-07 10:27:17 +01:00
sp_update_stmt_used_routines(thd, lex, &sp->m_sroutines,
rt->belong_to_view);
Bug#21039 Transaction cache not flushed after SELECT CREATE - Add prelocking for stored procedures that uses sp or sf - Update test result for sp_error(reported as bug#21294) - Make note about new error message from sp-error(bug#17244)
2006-07-26 12:40:26 +02:00
(void)sp->add_used_tables_to_table_list(thd, &lex->query_tables_last,
rt->belong_to_view);
Added Non-prelocked SP execution: Now a PROCEDURE doesn't enter/leave prelocked mode for its body, but lets each statement to get/release its own locks. This allows a broader set of statements to be executed inside PROCEDUREs (but breaks replication) This patch should fix BUG#8072, BUG#8766, BUG#9563, BUG#11126
2005-07-30 10:19:57 +02:00
}
* 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
sp->propagate_attributes(lex);
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
}
Added Non-prelocked SP execution: Now a PROCEDURE doesn't enter/leave prelocked mode for its body, but lets each statement to get/release its own locks. This allows a broader set of statements to be executed inside PROCEDUREs (but breaks replication) This patch should fix BUG#8072, BUG#8766, BUG#9563, BUG#11126
2005-07-30 10:19:57 +02:00
first= FALSE;
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
}
Fixed BUG#14233: Crash after tampering with the mysql.proc table Added error checking for errors when attempting to use stored procedures after the mysql.proc table has been dropped, corrupted, or tampered with. Test cases were put in a separate file (sp-destruct.test).
2005-10-26 15:34:57 +02:00
DBUG_RETURN(ret);
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
}
Doxygenized comments.
2007-10-11 20:37:45 +02:00
/**
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
Cache all routines from the set of used by statement, add tables used
by those routines to statement table list. Do the same for all routines
used by those routines.
Doxygenized comments.
2007-10-11 20:37:45 +02:00
@param thd thread context
@param lex LEX representing statement
@param first_no_prelock If true, don't add tables or cache routines used by
the body of the first routine (i.e. *start)
Bug#21039 Transaction cache not flushed after SELECT CREATE - Add prelocking for stored procedures that uses sp or sf - Update test result for sp_error(reported as bug#21294) - Make note about new error message from sp-error(bug#17244)
2006-07-26 12:40:26 +02:00
Doxygenized comments.
2007-10-11 20:37:45 +02:00
@retval
0 success
@retval
non-0 failure
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
*/
Fixed BUG#14233: Crash after tampering with the mysql.proc table Added error checking for errors when attempting to use stored procedures after the mysql.proc table has been dropped, corrupted, or tampered with. Test cases were put in a separate file (sp-destruct.test).
2005-10-26 15:34:57 +02:00
int
Bug#21039 Transaction cache not flushed after SELECT CREATE - Add prelocking for stored procedures that uses sp or sf - Update test result for sp_error(reported as bug#21294) - Make note about new error message from sp-error(bug#17244)
2006-07-26 12:40:26 +02:00
sp_cache_routines_and_add_tables(THD *thd, LEX *lex, bool first_no_prelock)
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
{
return sp_cache_routines_and_add_tables_aux(thd, lex,
Added Non-prelocked SP execution: Now a PROCEDURE doesn't enter/leave prelocked mode for its body, but lets each statement to get/release its own locks. This allows a broader set of statements to be executed inside PROCEDUREs (but breaks replication) This patch should fix BUG#8072, BUG#8766, BUG#9563, BUG#11126
2005-07-30 10:19:57 +02:00
(Sroutine_hash_entry *)lex->sroutines_list.first,
Bug#21039 Transaction cache not flushed after SELECT CREATE - Add prelocking for stored procedures that uses sp or sf - Update test result for sp_error(reported as bug#21294) - Make note about new error message from sp-error(bug#17244)
2006-07-26 12:40:26 +02:00
first_no_prelock);
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
}
Doxygenized comments.
2007-10-11 20:37:45 +02:00
/**
Add all routines used by view to the set of routines used by
statement.
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
Add tables used by those routines to statement table list. Do the same
for all routines used by these routines.
Doxygenized comments.
2007-10-11 20:37:45 +02:00
@param thd Thread context
@param lex LEX representing statement
@param view Table list element representing view
Merge bk-internal.mysql.com:/home/bk/mysql-5.0 into mysql.com:/home/dlenev/src/mysql-5.0-bg11555-2
2005-12-07 10:47:25 +01:00
Doxygenized comments.
2007-10-11 20:37:45 +02:00
@retval
0 success
@retval
non-0 failure
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
*/
Fixed BUG#14233: Crash after tampering with the mysql.proc table Added error checking for errors when attempting to use stored procedures after the mysql.proc table has been dropped, corrupted, or tampered with. Test cases were put in a separate file (sp-destruct.test).
2005-10-26 15:34:57 +02:00
int
Fix for bug #11555 "Stored procedures: current SP tables locking make impossible view security". We should not expose names of tables which are explicitly or implicitly (via routine or trigger) used by view even if we find that they are missing. So during building of list of prelocked tables for statement we track which routines (and therefore tables for these routines) are used from views. We mark elements of LEX::routines set which correspond to routines used in views by setting Sroutine_hash_entry::belong_to_view member to point to TABLE_LIST object for topmost view which uses routine. We propagate this mark to all routines which are used by this routine and which we add to this set. We also mark tables used by such routine which we add to the list of tables for prelocking as belonging to this view.
2005-12-07 10:27:17 +01:00
sp_cache_routines_and_add_tables_for_view(THD *thd, LEX *lex, TABLE_LIST *view)
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
{
Sroutine_hash_entry **last_cached_routine_ptr=
(Sroutine_hash_entry **)lex->sroutines_list.next;
Fix for bug #11555 "Stored procedures: current SP tables locking make impossible view security". We should not expose names of tables which are explicitly or implicitly (via routine or trigger) used by view even if we find that they are missing. So during building of list of prelocked tables for statement we track which routines (and therefore tables for these routines) are used from views. We mark elements of LEX::routines set which correspond to routines used in views by setting Sroutine_hash_entry::belong_to_view member to point to TABLE_LIST object for topmost view which uses routine. We propagate this mark to all routines which are used by this routine and which we add to this set. We also mark tables used by such routine which we add to the list of tables for prelocking as belonging to this view.
2005-12-07 10:27:17 +01:00
sp_update_stmt_used_routines(thd, lex, &view->view->sroutines_list,
view->top_table());
Bug#21039 Transaction cache not flushed after SELECT CREATE - Add prelocking for stored procedures that uses sp or sf - Update test result for sp_error(reported as bug#21294) - Make note about new error message from sp-error(bug#17244)
2006-07-26 12:40:26 +02:00
return sp_cache_routines_and_add_tables_aux(thd, lex,
*last_cached_routine_ptr, FALSE);
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
}
Doxygenized comments.
2007-10-11 20:37:45 +02:00
/**
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
Add triggers for table to the set of routines used by statement.
Add tables used by them to statement table list. Do the same for
all implicitly used routines.
Doxygenized comments.
2007-10-11 20:37:45 +02:00
@param thd thread context
@param lex LEX respresenting statement
@param table Table list element for table with trigger
Fixed BUG#14233: Crash after tampering with the mysql.proc table Added error checking for errors when attempting to use stored procedures after the mysql.proc table has been dropped, corrupted, or tampered with. Test cases were put in a separate file (sp-destruct.test).
2005-10-26 15:34:57 +02:00
Doxygenized comments.
2007-10-11 20:37:45 +02:00
@retval
0 success
@retval
non-0 failure
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
*/
Fixed BUG#14233: Crash after tampering with the mysql.proc table Added error checking for errors when attempting to use stored procedures after the mysql.proc table has been dropped, corrupted, or tampered with. Test cases were put in a separate file (sp-destruct.test).
2005-10-26 15:34:57 +02:00
int
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
sp_cache_routines_and_add_tables_for_triggers(THD *thd, LEX *lex,
Fix for bug #11555 "Stored procedures: current SP tables locking make impossible view security". We should not expose names of tables which are explicitly or implicitly (via routine or trigger) used by view even if we find that they are missing. So during building of list of prelocked tables for statement we track which routines (and therefore tables for these routines) are used from views. We mark elements of LEX::routines set which correspond to routines used in views by setting Sroutine_hash_entry::belong_to_view member to point to TABLE_LIST object for topmost view which uses routine. We propagate this mark to all routines which are used by this routine and which we add to this set. We also mark tables used by such routine which we add to the list of tables for prelocking as belonging to this view.
2005-12-07 10:27:17 +01:00
TABLE_LIST *table)
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
{
Fixed BUG#14233: Crash after tampering with the mysql.proc table Added error checking for errors when attempting to use stored procedures after the mysql.proc table has been dropped, corrupted, or tampered with. Test cases were put in a separate file (sp-destruct.test).
2005-10-26 15:34:57 +02:00
int ret= 0;
A fix and a test case for Bug#26141 mixing table types in trigger causes full table lock on innodb table. Also fixes Bug#28502 Triggers that update another innodb table will block on X lock unnecessarily (duplciate). Code review fixes. Both bugs' synopses are misleading: InnoDB table is not X locked. The statements, however, cannot proceed concurrently, but this happens due to lock conflicts for tables used in triggers, not for the InnoDB table. If a user had an InnoDB table, and two triggers, AFTER UPDATE and AFTER INSERT, competing for different resources (e.g. two distinct MyISAM tables), then these two triggers would not be able to execute concurrently. Moreover, INSERTS/UPDATES of the InnoDB table would not be able to run concurrently. The problem had other side-effects (see respective bug reports). This behavior was a consequence of a shortcoming of the pre-locking algorithm, which would not distinguish between different DML operations (e.g. INSERT and DELETE) and pre-lock all the tables that are used by any trigger defined on the subject table. The idea of the fix is to extend the pre-locking algorithm to keep track, for each table, what DML operation it is used for and not load triggers that are known to never be fired.
2007-07-12 20:26:41 +02:00
Sroutine_hash_entry **last_cached_routine_ptr=
(Sroutine_hash_entry **)lex->sroutines_list.next;
if (static_cast<int>(table->lock_type) >=
static_cast<int>(TL_WRITE_ALLOW_WRITE))
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
{
Fix for bugs #5892/6182/8751/8758/10994 (based on Antony's patch) "Triggers have the wrong namespace" "Triggers: duplicate names allowed" "Triggers: CREATE TRIGGER does not accept fully qualified names" "SHOW TRIGGERS"
2005-07-19 18:06:49 +02:00
for (int i= 0; i < (int)TRG_EVENT_MAX; i++)
Cleanups during review of new code Ensure mysql_close() is called if mysql_set_character_set() fails
2005-07-28 15:10:14 +02:00
{
A fix and a test case for Bug#26141 mixing table types in trigger causes full table lock on innodb table. Also fixes Bug#28502 Triggers that update another innodb table will block on X lock unnecessarily (duplciate). Code review fixes. Both bugs' synopses are misleading: InnoDB table is not X locked. The statements, however, cannot proceed concurrently, but this happens due to lock conflicts for tables used in triggers, not for the InnoDB table. If a user had an InnoDB table, and two triggers, AFTER UPDATE and AFTER INSERT, competing for different resources (e.g. two distinct MyISAM tables), then these two triggers would not be able to execute concurrently. Moreover, INSERTS/UPDATES of the InnoDB table would not be able to run concurrently. The problem had other side-effects (see respective bug reports). This behavior was a consequence of a shortcoming of the pre-locking algorithm, which would not distinguish between different DML operations (e.g. INSERT and DELETE) and pre-lock all the tables that are used by any trigger defined on the subject table. The idea of the fix is to extend the pre-locking algorithm to keep track, for each table, what DML operation it is used for and not load triggers that are known to never be fired.
2007-07-12 20:26:41 +02:00
if (table->trg_event_map &
static_cast<uint8>(1 << static_cast<int>(i)))
Cleanups during review of new code Ensure mysql_close() is called if mysql_set_character_set() fails
2005-07-28 15:10:14 +02:00
{
A fix and a test case for Bug#26141 mixing table types in trigger causes full table lock on innodb table. Also fixes Bug#28502 Triggers that update another innodb table will block on X lock unnecessarily (duplciate). Code review fixes. Both bugs' synopses are misleading: InnoDB table is not X locked. The statements, however, cannot proceed concurrently, but this happens due to lock conflicts for tables used in triggers, not for the InnoDB table. If a user had an InnoDB table, and two triggers, AFTER UPDATE and AFTER INSERT, competing for different resources (e.g. two distinct MyISAM tables), then these two triggers would not be able to execute concurrently. Moreover, INSERTS/UPDATES of the InnoDB table would not be able to run concurrently. The problem had other side-effects (see respective bug reports). This behavior was a consequence of a shortcoming of the pre-locking algorithm, which would not distinguish between different DML operations (e.g. INSERT and DELETE) and pre-lock all the tables that are used by any trigger defined on the subject table. The idea of the fix is to extend the pre-locking algorithm to keep track, for each table, what DML operation it is used for and not load triggers that are known to never be fired.
2007-07-12 20:26:41 +02:00
for (int j= 0; j < (int)TRG_ACTION_MAX; j++)
Better approach for prelocking of tables for stored routines execution and some SP-related cleanups. - We don't have separate stage for calculation of list of tables to be prelocked and doing implicit LOCK/UNLOCK any more. Instead we calculate this list at open_tables() and do implicit LOCK in lock_tables() (and UNLOCK in close_thread_tables()). Also now we support cases when same table (with same alias) is used several times in the same query in SP. - Cleaned up execution of SP. Moved all common code which handles LEX and does preparations before statement execution or complex expression evaluation to auxilary sp_lex_keeper class. Now all statements in SP (and corresponding instructions) that evaluate expression which can contain subquery have their own LEX.
2005-03-04 14:35:28 +01:00
{
A fix and a test case for Bug#26141 mixing table types in trigger causes full table lock on innodb table. Also fixes Bug#28502 Triggers that update another innodb table will block on X lock unnecessarily (duplciate). Code review fixes. Both bugs' synopses are misleading: InnoDB table is not X locked. The statements, however, cannot proceed concurrently, but this happens due to lock conflicts for tables used in triggers, not for the InnoDB table. If a user had an InnoDB table, and two triggers, AFTER UPDATE and AFTER INSERT, competing for different resources (e.g. two distinct MyISAM tables), then these two triggers would not be able to execute concurrently. Moreover, INSERTS/UPDATES of the InnoDB table would not be able to run concurrently. The problem had other side-effects (see respective bug reports). This behavior was a consequence of a shortcoming of the pre-locking algorithm, which would not distinguish between different DML operations (e.g. INSERT and DELETE) and pre-lock all the tables that are used by any trigger defined on the subject table. The idea of the fix is to extend the pre-locking algorithm to keep track, for each table, what DML operation it is used for and not load triggers that are known to never be fired.
2007-07-12 20:26:41 +02:00
/* We can have only one trigger per action type currently */
sp_head *trigger= table->table->triggers->bodies[i][j];
if (trigger &&
add_used_routine(lex, thd->stmt_arena, &trigger->m_sroutines_key,
table->belong_to_view))
{
trigger->add_used_tables_to_table_list(thd, &lex->query_tables_last,
table->belong_to_view);
Merge bodhi.(none):/opt/local/work/mysql-5.0-runtime into bodhi.(none):/opt/local/work/mysql-5.1-runtime
2007-07-16 21:31:36 +02:00
trigger->propagate_attributes(lex);
A fix and a test case for Bug#26141 mixing table types in trigger causes full table lock on innodb table. Also fixes Bug#28502 Triggers that update another innodb table will block on X lock unnecessarily (duplciate). Code review fixes. Both bugs' synopses are misleading: InnoDB table is not X locked. The statements, however, cannot proceed concurrently, but this happens due to lock conflicts for tables used in triggers, not for the InnoDB table. If a user had an InnoDB table, and two triggers, AFTER UPDATE and AFTER INSERT, competing for different resources (e.g. two distinct MyISAM tables), then these two triggers would not be able to execute concurrently. Moreover, INSERTS/UPDATES of the InnoDB table would not be able to run concurrently. The problem had other side-effects (see respective bug reports). This behavior was a consequence of a shortcoming of the pre-locking algorithm, which would not distinguish between different DML operations (e.g. INSERT and DELETE) and pre-lock all the tables that are used by any trigger defined on the subject table. The idea of the fix is to extend the pre-locking algorithm to keep track, for each table, what DML operation it is used for and not load triggers that are known to never be fired.
2007-07-12 20:26:41 +02:00
sp_update_stmt_used_routines(thd, lex,
&trigger->m_sroutines,
table->belong_to_view);
}
Better approach for prelocking of tables for stored routines execution and some SP-related cleanups. - We don't have separate stage for calculation of list of tables to be prelocked and doing implicit LOCK/UNLOCK any more. Instead we calculate this list at open_tables() and do implicit LOCK in lock_tables() (and UNLOCK in close_thread_tables()). Also now we support cases when same table (with same alias) is used several times in the same query in SP. - Cleaned up execution of SP. Moved all common code which handles LEX and does preparations before statement execution or complex expression evaluation to auxilary sp_lex_keeper class. Now all statements in SP (and corresponding instructions) that evaluate expression which can contain subquery have their own LEX.
2005-03-04 14:35:28 +01:00
}
Cleanups during review of new code Ensure mysql_close() is called if mysql_set_character_set() fails
2005-07-28 15:10:14 +02:00
}
}
Made FUNCTIONs work in insert and select queries, as well as nested function invocations. Had to add a cahing mechanism which is in parts an ugly kludge, but it will be reworked once the real SP caching is implemented.
2003-03-02 19:17:41 +01:00
}
A fix and a test case for Bug#26141 mixing table types in trigger causes full table lock on innodb table. Also fixes Bug#28502 Triggers that update another innodb table will block on X lock unnecessarily (duplciate). Code review fixes. Both bugs' synopses are misleading: InnoDB table is not X locked. The statements, however, cannot proceed concurrently, but this happens due to lock conflicts for tables used in triggers, not for the InnoDB table. If a user had an InnoDB table, and two triggers, AFTER UPDATE and AFTER INSERT, competing for different resources (e.g. two distinct MyISAM tables), then these two triggers would not be able to execute concurrently. Moreover, INSERTS/UPDATES of the InnoDB table would not be able to run concurrently. The problem had other side-effects (see respective bug reports). This behavior was a consequence of a shortcoming of the pre-locking algorithm, which would not distinguish between different DML operations (e.g. INSERT and DELETE) and pre-lock all the tables that are used by any trigger defined on the subject table. The idea of the fix is to extend the pre-locking algorithm to keep track, for each table, what DML operation it is used for and not load triggers that are known to never be fired.
2007-07-12 20:26:41 +02:00
ret= sp_cache_routines_and_add_tables_aux(thd, lex,
*last_cached_routine_ptr,
Post-merge fixes (merge from the main).
2007-07-16 22:59:21 +02:00
FALSE);
Fixed BUG#14233: Crash after tampering with the mysql.proc table Added error checking for errors when attempting to use stored procedures after the mysql.proc table has been dropped, corrupted, or tampered with. Test cases were put in a separate file (sp-destruct.test).
2005-10-26 15:34:57 +02:00
return ret;
Made stored FUNCTION invokation work almost always. Still buggy and unstable, and various known problems, but good enough for a checkpoint commit.
2003-02-26 19:22:29 +01:00
}
In order to make ALTER PROCEDURE|FUNCTION work correctly, and in general to make characteristics (and SHOW) work right, we had to separate the old definition blob in the mysql.proc table into separate fields for parameters, return type, and body, and handle the characteristics (like SQL SECURITY) separately... and then reassemble the CREATE string for parsing, of course. This is rather ugly, mostly the parser bit. (Hopefully that will be better with the new parser.)
2003-12-12 14:05:29 +01:00
Enable support of access to tables from triggers. Thus fix bug #8406 "Triggers crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
2005-07-09 19:51:59 +02:00
Doxygenized comments.
2007-10-11 20:37:45 +02:00
/**
Generates the CREATE... string from the table information.
@return
Returns TRUE on success, FALSE on (alloc) failure.
*/
Fixed BUG#2564: SHOW CREATE inconsistent W.R.T ANSI_QUOTES. It's not possible to quote the definition according to the current sql_mode setting, so instead we use the setting stored with the SP (that's how it's parsed anyway), and show this setting in the SHOW CREATE output.
2004-06-09 14:19:43 +02:00
static bool
create_string(THD *thd, String *buf,
Bug#36570: Parse error of CREATE PROCEDURE stmt with comments on \ slave The stored-routine code took the contents of the (lowest) parser and copied it directly to the binlog, which causes problems if there is a special case of interpretation at the parser level -- which there is, in the "/*!VER */" comments. The trailing "*/" caused errors on the slave, naturally. Now, since by that point we have /properly/ created parse-tree (as the rest of the server should do!) for the stored-routine CREATE, we can construct a perfect statement from that information, instead of writing uncertain information from an unknown parser state. Fortunately, there's already a function nearby that does exactly that. --- Update for Bug#36570. Qualify routine names with db name when writing to the binlog ONLY if the source text is qualified.
2008-05-16 01:13:24 +02:00
int type,
const char *db, ulong dblen,
const char *name, ulong namelen,
const char *params, ulong paramslen,
const char *returns, ulong returnslen,
const char *body, ulong bodylen,
st_sp_chistics *chistics,
Implementation of WL#2897: Complete definer support in the stored routines. The idea is to add DEFINER-clause in CREATE PROCEDURE and CREATE FUNCTION statements. Almost all support of definer in stored routines had been already done before this patch. NOTE: this patch changes behaviour of dumping stored routines in mysqldump. Before this patch, mysqldump did not dump DEFINER-clause for stored routines and this was documented behaviour. In order to get full information about stored routines, one should have dumped mysql.proc table. This patch changes this behaviour, so that DEFINER-clause is dumped. Since DEFINER-clause is not supported in CREATE PROCEDURE | FUNCTION statements before this patch, the clause is covered by additional version-specific comments.
2006-03-02 13:18:49 +01:00
const LEX_STRING *definer_user,
const LEX_STRING *definer_host)
In order to make ALTER PROCEDURE|FUNCTION work correctly, and in general to make characteristics (and SHOW) work right, we had to separate the old definition blob in the mysql.proc table into separate fields for parameters, return type, and body, and handle the characteristics (like SQL SECURITY) separately... and then reassemble the CREATE string for parsing, of course. This is rather ugly, mostly the parser bit. (Hopefully that will be better with the new parser.)
2003-12-12 14:05:29 +01:00
{
Fixed BUG#2564: SHOW CREATE inconsistent W.R.T ANSI_QUOTES. It's not possible to quote the definition according to the current sql_mode setting, so instead we use the setting stored with the SP (that's how it's parsed anyway), and show this setting in the SHOW CREATE output.
2004-06-09 14:19:43 +02:00
/* Make some room to begin with */
Bug#36570: Parse error of CREATE PROCEDURE stmt with comments on \ slave The stored-routine code took the contents of the (lowest) parser and copied it directly to the binlog, which causes problems if there is a special case of interpretation at the parser level -- which there is, in the "/*!VER */" comments. The trailing "*/" caused errors on the slave, naturally. Now, since by that point we have /properly/ created parse-tree (as the rest of the server should do!) for the stored-routine CREATE, we can construct a perfect statement from that information, instead of writing uncertain information from an unknown parser state. Fortunately, there's already a function nearby that does exactly that. --- Update for Bug#36570. Qualify routine names with db name when writing to the binlog ONLY if the source text is qualified.
2008-05-16 01:13:24 +02:00
if (buf->alloc(100 + dblen + 1 + namelen + paramslen + returnslen + bodylen +
Implementation of WL#2897: Complete definer support in the stored routines. The idea is to add DEFINER-clause in CREATE PROCEDURE and CREATE FUNCTION statements. Almost all support of definer in stored routines had been already done before this patch. NOTE: this patch changes behaviour of dumping stored routines in mysqldump. Before this patch, mysqldump did not dump DEFINER-clause for stored routines and this was documented behaviour. In order to get full information about stored routines, one should have dumped mysql.proc table. This patch changes this behaviour, so that DEFINER-clause is dumped. Since DEFINER-clause is not supported in CREATE PROCEDURE | FUNCTION statements before this patch, the clause is covered by additional version-specific comments.
2006-03-02 13:18:49 +01:00
chistics->comment.length + 10 /* length of " DEFINER= "*/ +
USER_HOST_BUFF_SIZE))
Fixed BUG#2564: SHOW CREATE inconsistent W.R.T ANSI_QUOTES. It's not possible to quote the definition according to the current sql_mode setting, so instead we use the setting stored with the SP (that's how it's parsed anyway), and show this setting in the SHOW CREATE output.
2004-06-09 14:19:43 +02:00
return FALSE;
Fixed memory leaks in SP Some code cleanup
2003-12-21 11:48:03 +01:00
merge
2005-11-23 00:29:25 +01:00
buf->append(STRING_WITH_LEN("CREATE "));
Implementation of WL#2897: Complete definer support in the stored routines. The idea is to add DEFINER-clause in CREATE PROCEDURE and CREATE FUNCTION statements. Almost all support of definer in stored routines had been already done before this patch. NOTE: this patch changes behaviour of dumping stored routines in mysqldump. Before this patch, mysqldump did not dump DEFINER-clause for stored routines and this was documented behaviour. In order to get full information about stored routines, one should have dumped mysql.proc table. This patch changes this behaviour, so that DEFINER-clause is dumped. Since DEFINER-clause is not supported in CREATE PROCEDURE | FUNCTION statements before this patch, the clause is covered by additional version-specific comments.
2006-03-02 13:18:49 +01:00
append_definer(thd, buf, definer_user, definer_host);
In order to make ALTER PROCEDURE|FUNCTION work correctly, and in general to make characteristics (and SHOW) work right, we had to separate the old definition blob in the mysql.proc table into separate fields for parameters, return type, and body, and handle the characteristics (like SQL SECURITY) separately... and then reassemble the CREATE string for parsing, of course. This is rather ugly, mostly the parser bit. (Hopefully that will be better with the new parser.)
2003-12-12 14:05:29 +01:00
if (type == TYPE_ENUM_FUNCTION)
merge
2005-11-23 00:29:25 +01:00
buf->append(STRING_WITH_LEN("FUNCTION "));
Fixed BUG#2564: SHOW CREATE inconsistent W.R.T ANSI_QUOTES. It's not possible to quote the definition according to the current sql_mode setting, so instead we use the setting stored with the SP (that's how it's parsed anyway), and show this setting in the SHOW CREATE output.
2004-06-09 14:19:43 +02:00
else
merge
2005-11-23 00:29:25 +01:00
buf->append(STRING_WITH_LEN("PROCEDURE "));
Bug#36570: Parse error of CREATE PROCEDURE stmt with comments on \ slave The stored-routine code took the contents of the (lowest) parser and copied it directly to the binlog, which causes problems if there is a special case of interpretation at the parser level -- which there is, in the "/*!VER */" comments. The trailing "*/" caused errors on the slave, naturally. Now, since by that point we have /properly/ created parse-tree (as the rest of the server should do!) for the stored-routine CREATE, we can construct a perfect statement from that information, instead of writing uncertain information from an unknown parser state. Fortunately, there's already a function nearby that does exactly that. --- Update for Bug#36570. Qualify routine names with db name when writing to the binlog ONLY if the source text is qualified.
2008-05-16 01:13:24 +02:00
if (dblen > 0)
{
append_identifier(thd, buf, db, dblen);
buf->append('.');
}
Bug#36570: Parse error of CREATE PROCEDURE stmt with comments on \ slave The stored-routine code took the contents of the (lowest) parser and copied it directly to the binlog, which causes problems if there is a special case of interpretation at the parser level -- which there is, in the "/*!VER */" comments. The trailing "*/" caused errors on the slave, naturally. Now, since by that point we have /properly/ created parse-tree (as the rest of the server should do!) for the stored-routine CREATE, we can construct a perfect statement from that information, instead of writing uncertain information from an unknown parser state. Fortunately, there's already a function nearby that does exactly that.
2008-05-15 01:23:54 +02:00
append_identifier(thd, buf, name, namelen);
Fixed BUG#2564: SHOW CREATE inconsistent W.R.T ANSI_QUOTES. It's not possible to quote the definition according to the current sql_mode setting, so instead we use the setting stored with the SP (that's how it's parsed anyway), and show this setting in the SHOW CREATE output.
2004-06-09 14:19:43 +02:00
buf->append('(');
buf->append(params, paramslen);
buf->append(')');
if (type == TYPE_ENUM_FUNCTION)
{
merge
2005-11-23 00:29:25 +01:00
buf->append(STRING_WITH_LEN(" RETURNS "));
Fixed BUG#2564: SHOW CREATE inconsistent W.R.T ANSI_QUOTES. It's not possible to quote the definition according to the current sql_mode setting, so instead we use the setting stored with the SP (that's how it's parsed anyway), and show this setting in the SHOW CREATE output.
2004-06-09 14:19:43 +02:00
buf->append(returns, returnslen);
}
buf->append('\n');
Implemented the stored procedure data access characteristics: NO SQL CONTAINS SQL (default) READS SQL DATA MODIFIES SQL DATA These are needed as hints for the replication. (Before this, we did have the default in the mysql.proc table, but no support in the parser.)
2004-10-14 18:07:09 +02:00
switch (chistics->daccess) {
case SP_NO_SQL:
merge
2005-11-23 00:29:25 +01:00
buf->append(STRING_WITH_LEN(" NO SQL\n"));
Implemented the stored procedure data access characteristics: NO SQL CONTAINS SQL (default) READS SQL DATA MODIFIES SQL DATA These are needed as hints for the replication. (Before this, we did have the default in the mysql.proc table, but no support in the parser.)
2004-10-14 18:07:09 +02:00
break;
case SP_READS_SQL_DATA:
merge
2005-11-23 00:29:25 +01:00
buf->append(STRING_WITH_LEN(" READS SQL DATA\n"));
Implemented the stored procedure data access characteristics: NO SQL CONTAINS SQL (default) READS SQL DATA MODIFIES SQL DATA These are needed as hints for the replication. (Before this, we did have the default in the mysql.proc table, but no support in the parser.)
2004-10-14 18:07:09 +02:00
break;
case SP_MODIFIES_SQL_DATA:
merge
2005-11-23 00:29:25 +01:00
buf->append(STRING_WITH_LEN(" MODIFIES SQL DATA\n"));
Implemented the stored procedure data access characteristics: NO SQL CONTAINS SQL (default) READS SQL DATA MODIFIES SQL DATA These are needed as hints for the replication. (Before this, we did have the default in the mysql.proc table, but no support in the parser.)
2004-10-14 18:07:09 +02:00
break;
Fixes after merge with 4.1 FOUND is not a reserved keyword anymore Added Item_field::set_no_const_sub() to be able to mark fields that can't be substituted Added 'simple_select' method to be able to quickly determinate if a select_result is a normal SELECT Note that the 5.0 tree is not yet up to date: Sanja will have to fix multi-update-locks for this merge to be complete
2004-11-03 11:39:38 +01:00
case SP_DEFAULT_ACCESS:
case SP_CONTAINS_SQL:
/* Do nothing */
break;
Implemented the stored procedure data access characteristics: NO SQL CONTAINS SQL (default) READS SQL DATA MODIFIES SQL DATA These are needed as hints for the replication. (Before this, we did have the default in the mysql.proc table, but no support in the parser.)
2004-10-14 18:07:09 +02:00
}
In order to make ALTER PROCEDURE|FUNCTION work correctly, and in general to make characteristics (and SHOW) work right, we had to separate the old definition blob in the mysql.proc table into separate fields for parameters, return type, and body, and handle the characteristics (like SQL SECURITY) separately... and then reassemble the CREATE string for parsing, of course. This is rather ugly, mostly the parser bit. (Hopefully that will be better with the new parser.)
2003-12-12 14:05:29 +01:00
if (chistics->detistic)
merge
2005-11-23 00:29:25 +01:00
buf->append(STRING_WITH_LEN(" DETERMINISTIC\n"));
Implemented the stored procedure data access characteristics: NO SQL CONTAINS SQL (default) READS SQL DATA MODIFIES SQL DATA These are needed as hints for the replication. (Before this, we did have the default in the mysql.proc table, but no support in the parser.)
2004-10-14 18:07:09 +02:00
if (chistics->suid == SP_IS_NOT_SUID)
merge
2005-11-23 00:29:25 +01:00
buf->append(STRING_WITH_LEN(" SQL SECURITY INVOKER\n"));
WL#1365: Implement definer's rights execution of stored procedures. (Also put the hostpart back in the definer column.)
2003-12-13 16:40:52 +01:00
if (chistics->comment.length)
Update for VC++ (Fixed project files, compiler warnings etc..)
2003-12-21 01:07:45 +01:00
{
merge
2005-11-23 00:29:25 +01:00
buf->append(STRING_WITH_LEN(" COMMENT "));
Fixed BUG#2564: SHOW CREATE inconsistent W.R.T ANSI_QUOTES. It's not possible to quote the definition according to the current sql_mode setting, so instead we use the setting stored with the SP (that's how it's parsed anyway), and show this setting in the SHOW CREATE output.
2004-06-09 14:19:43 +02:00
append_unescaped(buf, chistics->comment.str, chistics->comment.length);
buf->append('\n');
Update for VC++ (Fixed project files, compiler warnings etc..)
2003-12-21 01:07:45 +01:00
}
Fixed BUG#2564: SHOW CREATE inconsistent W.R.T ANSI_QUOTES. It's not possible to quote the definition according to the current sql_mode setting, so instead we use the setting stored with the SP (that's how it's parsed anyway), and show this setting in the SHOW CREATE output.
2004-06-09 14:19:43 +02:00
buf->append(body, bodylen);
return TRUE;
In order to make ALTER PROCEDURE|FUNCTION work correctly, and in general to make characteristics (and SHOW) work right, we had to separate the old definition blob in the mysql.proc table into separate fields for parameters, return type, and body, and handle the characteristics (like SQL SECURITY) separately... and then reassemble the CREATE string for parsing, of course. This is rather ugly, mostly the parser bit. (Hopefully that will be better with the new parser.)
2003-12-12 14:05:29 +01:00
}
Reference in a new issue Copy permalink