2002-06-12 23:13:12 +02:00
|
|
|
/* Copyright (C) 1995-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
|
|
|
|
the Free Software Foundation; either version 2 of the License, or
|
|
|
|
(at your option) any later version.
|
|
|
|
|
|
|
|
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
|
2003-03-25 13:46:10 +01:00
|
|
|
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */
|
2002-06-12 23:13:12 +02:00
|
|
|
|
|
|
|
/**********************************************************************
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
This file contains the implementation of prepared statements.
|
2002-06-12 23:13:12 +02:00
|
|
|
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
When one prepares a statement:
|
2002-06-12 23:13:12 +02:00
|
|
|
|
2005-06-17 21:26:25 +02:00
|
|
|
- Server gets the query from client with command 'COM_STMT_PREPARE';
|
2002-11-27 03:51:38 +01:00
|
|
|
in the following format:
|
2005-06-17 21:26:25 +02:00
|
|
|
[COM_STMT_PREPARE:1] [query]
|
2005-06-08 17:57:26 +02:00
|
|
|
- Parse the query and recognize any parameter markers '?' and
|
2002-11-27 03:51:38 +01:00
|
|
|
store its information list in lex->param_list
|
2005-06-08 17:57:26 +02:00
|
|
|
- Allocate a new statement for this prepare; and keep this in
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
'thd->stmt_map'.
|
2005-06-08 17:57:26 +02:00
|
|
|
- Without executing the query, return back to client the total
|
2002-06-12 23:13:12 +02:00
|
|
|
number of parameters along with result-set metadata information
|
2002-11-27 03:51:38 +01:00
|
|
|
(if any) in the following format:
|
2003-01-20 23:00:50 +01:00
|
|
|
[STMT_ID:4]
|
|
|
|
[Column_count:2]
|
|
|
|
[Param_count:2]
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
[Params meta info (stubs only for now)] (if Param_count > 0)
|
2003-01-20 23:00:50 +01:00
|
|
|
[Columns meta info] (if Column_count > 0)
|
2005-06-08 17:57:26 +02:00
|
|
|
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
When one executes a statement:
|
2002-06-12 23:13:12 +02:00
|
|
|
|
2005-06-17 21:26:25 +02:00
|
|
|
- Server gets the command 'COM_STMT_EXECUTE' to execute the
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
previously prepared query. If there are any parameter markers, then the
|
|
|
|
client will send the data in the following format:
|
2005-06-17 21:26:25 +02:00
|
|
|
[COM_STMT_EXECUTE:1]
|
2002-11-27 03:51:38 +01:00
|
|
|
[STMT_ID:4]
|
|
|
|
[NULL_BITS:(param_count+7)/8)]
|
|
|
|
[TYPES_SUPPLIED_BY_CLIENT(0/1):1]
|
|
|
|
[[length]data]
|
2005-06-08 17:57:26 +02:00
|
|
|
[[length]data] .. [[length]data].
|
|
|
|
(Note: Except for string/binary types; all other types will not be
|
2002-11-27 03:51:38 +01:00
|
|
|
supplied with length field)
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
- If it is a first execute or types of parameters were altered by client,
|
|
|
|
then setup the conversion routines.
|
|
|
|
- Assign parameter items from the supplied data.
|
2005-06-08 17:57:26 +02:00
|
|
|
- Execute the query without re-parsing and send back the results
|
2002-06-12 23:13:12 +02:00
|
|
|
to client
|
|
|
|
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
When one supplies long data for a placeholder:
|
2002-11-27 03:51:38 +01:00
|
|
|
|
2005-06-17 21:26:25 +02:00
|
|
|
- Server gets the long data in pieces with command type
|
|
|
|
'COM_STMT_SEND_LONG_DATA'.
|
2002-06-12 23:13:12 +02:00
|
|
|
- The packet recieved will have the format as:
|
2005-06-17 21:26:25 +02:00
|
|
|
[COM_STMT_SEND_LONG_DATA:1][STMT_ID:4][parameter_number:2][data]
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
- data from the packet is appended to the long data value buffer for this
|
2004-05-25 17:52:05 +02:00
|
|
|
placeholder.
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
- It's up to the client to stop supplying data chunks at any point. The
|
|
|
|
server doesn't care; also, the server doesn't notify the client whether
|
|
|
|
it got the data or not; if there is any error, then it will be returned
|
|
|
|
at statement execute.
|
2002-10-02 12:33:08 +02:00
|
|
|
|
2002-06-12 23:13:12 +02:00
|
|
|
***********************************************************************/
|
|
|
|
|
|
|
|
#include "mysql_priv.h"
|
2003-01-18 21:58:19 +01:00
|
|
|
#include "sql_select.h" // for JOIN
|
2005-09-22 00:11:21 +02:00
|
|
|
#include "sql_cursor.h"
|
2003-05-23 15:32:31 +02:00
|
|
|
#include "sp_head.h"
|
2004-11-05 20:02:07 +01:00
|
|
|
#include "sp.h"
|
2005-08-09 01:23:34 +02:00
|
|
|
#include "sp_cache.h"
|
2003-12-20 00:16:10 +01:00
|
|
|
#ifdef EMBEDDED_LIBRARY
|
|
|
|
/* include MYSQL_BIND headers */
|
|
|
|
#include <mysql.h>
|
2004-08-03 12:32:21 +02:00
|
|
|
#else
|
|
|
|
#include <mysql_com.h>
|
2003-12-20 00:16:10 +01:00
|
|
|
#endif
|
2002-06-12 23:13:12 +02:00
|
|
|
|
2005-09-22 00:11:21 +02:00
|
|
|
/* A result class used to send cursor rows using the binary protocol. */
|
|
|
|
|
|
|
|
class Select_fetch_protocol_prep: public select_send
|
|
|
|
{
|
|
|
|
Protocol_prep protocol;
|
|
|
|
public:
|
|
|
|
Select_fetch_protocol_prep(THD *thd);
|
|
|
|
virtual bool send_fields(List<Item> &list, uint flags);
|
|
|
|
virtual bool send_data(List<Item> &items);
|
|
|
|
virtual bool send_eof();
|
2006-02-24 17:34:15 +01:00
|
|
|
#ifdef EMBEDDED_LIBRARY
|
|
|
|
void begin_dataset()
|
|
|
|
{
|
|
|
|
protocol.begin_dataset();
|
|
|
|
}
|
|
|
|
#endif
|
2005-09-22 00:11:21 +02:00
|
|
|
};
|
|
|
|
|
2003-12-20 00:16:10 +01:00
|
|
|
/******************************************************************************
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
Prepared_statement: a statement that can contain placeholders
|
2003-12-20 00:16:10 +01:00
|
|
|
******************************************************************************/
|
2003-04-04 19:33:17 +02:00
|
|
|
|
2003-12-20 00:16:10 +01:00
|
|
|
class Prepared_statement: public Statement
|
|
|
|
{
|
|
|
|
public:
|
2005-10-06 16:54:43 +02:00
|
|
|
enum flag_values
|
|
|
|
{
|
|
|
|
IS_IN_USE= 1
|
|
|
|
};
|
|
|
|
|
2003-12-20 00:16:10 +01:00
|
|
|
THD *thd;
|
2005-09-22 00:11:21 +02:00
|
|
|
Select_fetch_protocol_prep result;
|
2005-08-08 17:24:56 +02:00
|
|
|
Protocol *protocol;
|
2004-03-02 20:39:50 +01:00
|
|
|
Item_param **param_array;
|
2003-12-20 00:16:10 +01:00
|
|
|
uint param_count;
|
|
|
|
uint last_errno;
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
uint flags;
|
2003-12-20 00:16:10 +01:00
|
|
|
char last_error[MYSQL_ERRMSG_SIZE];
|
|
|
|
#ifndef EMBEDDED_LIBRARY
|
2004-03-15 18:20:47 +01:00
|
|
|
bool (*set_params)(Prepared_statement *st, uchar *data, uchar *data_end,
|
2004-05-24 19:08:22 +02:00
|
|
|
uchar *read_pos, String *expanded_query);
|
2003-10-01 13:44:57 +02:00
|
|
|
#else
|
2004-05-24 19:08:22 +02:00
|
|
|
bool (*set_params_data)(Prepared_statement *st, String *expanded_query);
|
2003-10-01 13:44:57 +02:00
|
|
|
#endif
|
2005-06-08 17:57:26 +02:00
|
|
|
bool (*set_params_from_vars)(Prepared_statement *stmt,
|
2004-05-24 19:08:22 +02:00
|
|
|
List<LEX_STRING>& varnames,
|
|
|
|
String *expanded_query);
|
2003-12-20 00:16:10 +01:00
|
|
|
public:
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
Prepared_statement(THD *thd_arg, Protocol *protocol_arg);
|
2003-12-20 00:16:10 +01:00
|
|
|
virtual ~Prepared_statement();
|
2004-06-01 15:27:40 +02:00
|
|
|
void setup_set_params();
|
2005-06-15 19:58:35 +02:00
|
|
|
virtual Query_arena::Type type() const;
|
2005-09-22 00:11:21 +02:00
|
|
|
virtual void cleanup_stmt();
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
bool set_name(LEX_STRING *name);
|
2005-09-22 00:11:21 +02:00
|
|
|
inline void close_cursor() { delete cursor; cursor= 0; }
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
|
|
|
|
bool prepare(const char *packet, uint packet_length);
|
|
|
|
bool execute(String *expanded_query, bool open_cursor);
|
|
|
|
/* Destroy this statement */
|
|
|
|
bool deallocate();
|
|
|
|
};
|
2002-10-02 12:33:08 +02:00
|
|
|
|
2005-09-13 10:15:48 +02:00
|
|
|
|
2003-12-20 00:16:10 +01:00
|
|
|
/******************************************************************************
|
|
|
|
Implementation
|
|
|
|
******************************************************************************/
|
2002-10-02 12:33:08 +02:00
|
|
|
|
|
|
|
|
2003-12-20 00:16:10 +01:00
|
|
|
inline bool is_param_null(const uchar *pos, ulong param_no)
|
2002-10-02 12:33:08 +02:00
|
|
|
{
|
2003-12-20 00:16:10 +01:00
|
|
|
return pos[param_no/8] & (1 << (param_no & 7));
|
2002-10-02 12:33:08 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
Find a prepared statement in the statement map by id.
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
find_prepared_statement()
|
|
|
|
thd thread handle
|
|
|
|
id statement id
|
|
|
|
where the place from which this function is called (for
|
|
|
|
error reporting).
|
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
Try to find a prepared statement and set THD error if it's not found.
|
|
|
|
|
|
|
|
RETURN VALUE
|
|
|
|
0 if the statement was not found, a pointer otherwise.
|
2002-10-02 12:33:08 +02:00
|
|
|
*/
|
|
|
|
|
2003-12-20 00:16:10 +01:00
|
|
|
static Prepared_statement *
|
2004-10-20 03:04:37 +02:00
|
|
|
find_prepared_statement(THD *thd, ulong id, const char *where)
|
2003-12-20 00:16:10 +01:00
|
|
|
{
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
/*
|
|
|
|
To strictly separate namespaces of SQL prepared statements and C API
|
|
|
|
prepared statements find() will return 0 if there is a named prepared
|
|
|
|
statement with such id.
|
|
|
|
*/
|
2003-12-20 00:16:10 +01:00
|
|
|
Statement *stmt= thd->stmt_map.find(id);
|
|
|
|
|
2005-06-15 19:58:35 +02:00
|
|
|
if (stmt == 0 || stmt->type() != Query_arena::PREPARED_STATEMENT)
|
2003-12-20 00:16:10 +01:00
|
|
|
{
|
2004-05-21 02:27:50 +02:00
|
|
|
char llbuf[22];
|
2005-05-12 09:16:12 +02:00
|
|
|
my_error(ER_UNKNOWN_STMT_HANDLER, MYF(0), sizeof(llbuf), llstr(id, llbuf),
|
|
|
|
where);
|
2003-12-20 00:16:10 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
return (Prepared_statement *) stmt;
|
2002-10-02 12:33:08 +02:00
|
|
|
}
|
|
|
|
|
2003-12-20 00:16:10 +01:00
|
|
|
|
2002-10-02 12:33:08 +02:00
|
|
|
/*
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
Send prepared statement id and metadata to the client after prepare.
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
send_prep_stmt()
|
|
|
|
|
|
|
|
RETURN VALUE
|
|
|
|
0 in case of success, 1 otherwise
|
2002-10-02 12:33:08 +02:00
|
|
|
*/
|
|
|
|
|
2003-09-12 16:35:34 +02:00
|
|
|
#ifndef EMBEDDED_LIBRARY
|
2003-12-20 00:16:10 +01:00
|
|
|
static bool send_prep_stmt(Prepared_statement *stmt, uint columns)
|
2002-10-02 12:33:08 +02:00
|
|
|
{
|
2003-12-20 00:16:10 +01:00
|
|
|
NET *net= &stmt->thd->net;
|
2005-01-04 12:46:53 +01:00
|
|
|
char buff[12];
|
|
|
|
uint tmp;
|
2004-11-03 11:39:38 +01:00
|
|
|
DBUG_ENTER("send_prep_stmt");
|
|
|
|
|
2004-03-02 20:39:50 +01:00
|
|
|
buff[0]= 0; /* OK packet indicator */
|
2003-12-20 00:16:10 +01:00
|
|
|
int4store(buff+1, stmt->id);
|
2003-04-17 01:47:01 +02:00
|
|
|
int2store(buff+5, columns);
|
|
|
|
int2store(buff+7, stmt->param_count);
|
2005-01-04 12:46:53 +01:00
|
|
|
buff[9]= 0; // Guard against a 4.1 client
|
|
|
|
tmp= min(stmt->thd->total_warn_count, 65535);
|
|
|
|
int2store(buff+10, tmp);
|
|
|
|
|
2004-03-31 00:27:49 +02:00
|
|
|
/*
|
|
|
|
Send types and names of placeholders to the client
|
|
|
|
XXX: fix this nasty upcast from List<Item_param> to List<Item>
|
|
|
|
*/
|
2005-06-08 17:57:26 +02:00
|
|
|
DBUG_RETURN(my_net_write(net, buff, sizeof(buff)) ||
|
2004-11-03 11:39:38 +01:00
|
|
|
(stmt->param_count &&
|
|
|
|
stmt->thd->protocol_simple.send_fields((List<Item> *)
|
|
|
|
&stmt->lex->param_list,
|
2004-11-04 14:06:24 +01:00
|
|
|
Protocol::SEND_EOF)));
|
2003-09-12 16:35:34 +02:00
|
|
|
}
|
2002-12-16 14:33:29 +01:00
|
|
|
#else
|
2003-12-20 00:16:10 +01:00
|
|
|
static bool send_prep_stmt(Prepared_statement *stmt,
|
|
|
|
uint columns __attribute__((unused)))
|
2003-09-12 16:35:34 +02:00
|
|
|
{
|
2003-09-16 13:06:25 +02:00
|
|
|
THD *thd= stmt->thd;
|
|
|
|
|
2003-12-20 00:16:10 +01:00
|
|
|
thd->client_stmt_id= stmt->id;
|
2003-09-16 13:06:25 +02:00
|
|
|
thd->client_param_count= stmt->param_count;
|
2004-10-20 03:04:37 +02:00
|
|
|
thd->clear_error();
|
2003-09-12 16:35:34 +02:00
|
|
|
|
2003-09-16 13:06:25 +02:00
|
|
|
return 0;
|
2002-10-02 12:33:08 +02:00
|
|
|
}
|
2003-11-26 22:16:34 +01:00
|
|
|
#endif /*!EMBEDDED_LIBRARY*/
|
2002-10-02 12:33:08 +02:00
|
|
|
|
2002-06-12 23:13:12 +02:00
|
|
|
|
|
|
|
/*
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
Read the length of the parameter data and return it back to
|
|
|
|
the caller.
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
get_param_length()
|
|
|
|
packet a pointer to the data
|
|
|
|
len remaining packet length
|
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
Read data length, position the packet to the first byte after it,
|
|
|
|
and return the length to the caller.
|
|
|
|
|
|
|
|
RETURN VALUE
|
|
|
|
Length of data piece.
|
2002-06-12 23:13:12 +02:00
|
|
|
*/
|
|
|
|
|
2003-10-01 13:44:57 +02:00
|
|
|
#ifndef EMBEDDED_LIBRARY
|
2004-03-15 18:20:47 +01:00
|
|
|
static ulong get_param_length(uchar **packet, ulong len)
|
2002-06-12 23:13:12 +02:00
|
|
|
{
|
|
|
|
reg1 uchar *pos= *packet;
|
2004-03-15 18:20:47 +01:00
|
|
|
if (len < 1)
|
|
|
|
return 0;
|
2002-06-12 23:13:12 +02:00
|
|
|
if (*pos < 251)
|
|
|
|
{
|
|
|
|
(*packet)++;
|
|
|
|
return (ulong) *pos;
|
|
|
|
}
|
2004-03-15 18:20:47 +01:00
|
|
|
if (len < 3)
|
|
|
|
return 0;
|
2002-06-12 23:13:12 +02:00
|
|
|
if (*pos == 252)
|
|
|
|
{
|
|
|
|
(*packet)+=3;
|
|
|
|
return (ulong) uint2korr(pos+1);
|
|
|
|
}
|
2004-03-15 18:20:47 +01:00
|
|
|
if (len < 4)
|
|
|
|
return 0;
|
2002-06-12 23:13:12 +02:00
|
|
|
if (*pos == 253)
|
|
|
|
{
|
|
|
|
(*packet)+=4;
|
|
|
|
return (ulong) uint3korr(pos+1);
|
|
|
|
}
|
2004-03-15 18:20:47 +01:00
|
|
|
if (len < 5)
|
|
|
|
return 0;
|
2005-06-08 17:57:26 +02:00
|
|
|
(*packet)+=9; // Must be 254 when here
|
2004-06-05 22:33:16 +02:00
|
|
|
/*
|
|
|
|
In our client-server protocol all numbers bigger than 2^24
|
|
|
|
stored as 8 bytes with uint8korr. Here we always know that
|
|
|
|
parameter length is less than 2^4 so don't look at the second
|
|
|
|
4 bytes. But still we need to obey the protocol hence 9 in the
|
|
|
|
assignment above.
|
|
|
|
*/
|
2002-06-12 23:13:12 +02:00
|
|
|
return (ulong) uint4korr(pos+1);
|
|
|
|
}
|
2003-10-01 13:44:57 +02:00
|
|
|
#else
|
2004-03-15 18:20:47 +01:00
|
|
|
#define get_param_length(packet, len) len
|
2003-10-01 13:44:57 +02:00
|
|
|
#endif /*!EMBEDDED_LIBRARY*/
|
|
|
|
|
2002-11-22 19:04:42 +01:00
|
|
|
/*
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
Data conversion routines.
|
|
|
|
|
2004-03-02 20:39:50 +01:00
|
|
|
SYNOPSIS
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
set_param_xx()
|
|
|
|
param parameter item
|
|
|
|
pos input data buffer
|
|
|
|
len length of data in the buffer
|
2002-11-22 19:04:42 +01:00
|
|
|
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
DESCRIPTION
|
|
|
|
All these functions read the data from pos, convert it to requested
|
|
|
|
type and assign to param; pos is advanced to predefined length.
|
2002-11-22 19:04:42 +01:00
|
|
|
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
Make a note that the NULL handling is examined at first execution
|
|
|
|
(i.e. when input types altered) and for all subsequent executions
|
|
|
|
we don't read any values for this.
|
2002-11-22 19:04:42 +01:00
|
|
|
|
2004-03-02 20:39:50 +01:00
|
|
|
RETURN VALUE
|
|
|
|
none
|
2002-06-12 23:13:12 +02:00
|
|
|
*/
|
|
|
|
|
2004-05-25 00:03:49 +02:00
|
|
|
static void set_param_tiny(Item_param *param, uchar **pos, ulong len)
|
2002-06-12 23:13:12 +02:00
|
|
|
{
|
2004-03-15 18:20:47 +01:00
|
|
|
#ifndef EMBEDDED_LIBRARY
|
|
|
|
if (len < 1)
|
|
|
|
return;
|
|
|
|
#endif
|
2004-04-30 01:00:19 +02:00
|
|
|
int8 value= (int8) **pos;
|
2005-06-08 17:57:26 +02:00
|
|
|
param->set_int(param->unsigned_flag ? (longlong) ((uint8) value) :
|
2004-05-25 00:03:49 +02:00
|
|
|
(longlong) value, 4);
|
2002-11-22 19:04:42 +01:00
|
|
|
*pos+= 1;
|
|
|
|
}
|
|
|
|
|
2004-05-25 00:03:49 +02:00
|
|
|
static void set_param_short(Item_param *param, uchar **pos, ulong len)
|
2002-11-22 19:04:42 +01:00
|
|
|
{
|
2004-05-25 00:03:49 +02:00
|
|
|
int16 value;
|
2004-03-15 18:20:47 +01:00
|
|
|
#ifndef EMBEDDED_LIBRARY
|
|
|
|
if (len < 2)
|
|
|
|
return;
|
2004-05-25 00:03:49 +02:00
|
|
|
value= sint2korr(*pos);
|
2004-05-18 16:13:21 +02:00
|
|
|
#else
|
|
|
|
shortget(value, *pos);
|
2004-03-15 18:20:47 +01:00
|
|
|
#endif
|
2004-04-30 01:00:19 +02:00
|
|
|
param->set_int(param->unsigned_flag ? (longlong) ((uint16) value) :
|
2004-05-25 00:03:49 +02:00
|
|
|
(longlong) value, 6);
|
2002-11-22 19:04:42 +01:00
|
|
|
*pos+= 2;
|
|
|
|
}
|
|
|
|
|
2004-05-25 00:03:49 +02:00
|
|
|
static void set_param_int32(Item_param *param, uchar **pos, ulong len)
|
2002-11-22 19:04:42 +01:00
|
|
|
{
|
2004-05-25 00:03:49 +02:00
|
|
|
int32 value;
|
2004-03-15 18:20:47 +01:00
|
|
|
#ifndef EMBEDDED_LIBRARY
|
|
|
|
if (len < 4)
|
|
|
|
return;
|
2004-05-25 00:03:49 +02:00
|
|
|
value= sint4korr(*pos);
|
2004-05-18 16:13:21 +02:00
|
|
|
#else
|
|
|
|
longget(value, *pos);
|
2004-03-15 18:20:47 +01:00
|
|
|
#endif
|
2004-04-30 01:00:19 +02:00
|
|
|
param->set_int(param->unsigned_flag ? (longlong) ((uint32) value) :
|
2004-05-25 00:03:49 +02:00
|
|
|
(longlong) value, 11);
|
2002-11-22 19:04:42 +01:00
|
|
|
*pos+= 4;
|
|
|
|
}
|
|
|
|
|
2004-05-25 00:03:49 +02:00
|
|
|
static void set_param_int64(Item_param *param, uchar **pos, ulong len)
|
2002-11-22 19:04:42 +01:00
|
|
|
{
|
2004-05-25 00:03:49 +02:00
|
|
|
longlong value;
|
2004-03-15 18:20:47 +01:00
|
|
|
#ifndef EMBEDDED_LIBRARY
|
|
|
|
if (len < 8)
|
|
|
|
return;
|
2004-05-25 00:03:49 +02:00
|
|
|
value= (longlong) sint8korr(*pos);
|
2004-05-18 16:13:21 +02:00
|
|
|
#else
|
|
|
|
longlongget(value, *pos);
|
2004-03-15 18:20:47 +01:00
|
|
|
#endif
|
2004-05-25 00:03:49 +02:00
|
|
|
param->set_int(value, 21);
|
2002-11-22 19:04:42 +01:00
|
|
|
*pos+= 8;
|
|
|
|
}
|
|
|
|
|
2004-05-25 00:03:49 +02:00
|
|
|
static void set_param_float(Item_param *param, uchar **pos, ulong len)
|
2002-11-22 19:04:42 +01:00
|
|
|
{
|
2005-07-15 08:17:57 +02:00
|
|
|
float data;
|
2004-03-15 18:20:47 +01:00
|
|
|
#ifndef EMBEDDED_LIBRARY
|
|
|
|
if (len < 4)
|
|
|
|
return;
|
2002-11-22 19:04:42 +01:00
|
|
|
float4get(data,*pos);
|
2005-07-15 08:17:57 +02:00
|
|
|
#else
|
2005-07-19 18:25:05 +02:00
|
|
|
floatget(data, *pos);
|
2005-07-15 08:17:57 +02:00
|
|
|
#endif
|
2002-11-22 19:04:42 +01:00
|
|
|
param->set_double((double) data);
|
|
|
|
*pos+= 4;
|
|
|
|
}
|
|
|
|
|
2004-05-25 00:03:49 +02:00
|
|
|
static void set_param_double(Item_param *param, uchar **pos, ulong len)
|
2002-11-22 19:04:42 +01:00
|
|
|
{
|
2005-07-15 08:17:57 +02:00
|
|
|
double data;
|
2004-03-15 18:20:47 +01:00
|
|
|
#ifndef EMBEDDED_LIBRARY
|
|
|
|
if (len < 8)
|
|
|
|
return;
|
2002-11-22 19:04:42 +01:00
|
|
|
float8get(data,*pos);
|
2005-07-15 08:17:57 +02:00
|
|
|
#else
|
2005-07-19 18:25:05 +02:00
|
|
|
doubleget(data, *pos);
|
2005-07-15 08:17:57 +02:00
|
|
|
#endif
|
2002-11-22 19:04:42 +01:00
|
|
|
param->set_double((double) data);
|
|
|
|
*pos+= 8;
|
|
|
|
}
|
|
|
|
|
2005-02-08 23:50:45 +01:00
|
|
|
static void set_param_decimal(Item_param *param, uchar **pos, ulong len)
|
|
|
|
{
|
|
|
|
ulong length= get_param_length(pos, len);
|
|
|
|
param->set_decimal((char*)*pos, length);
|
2006-01-26 10:15:47 +01:00
|
|
|
*pos+= length;
|
2005-02-08 23:50:45 +01:00
|
|
|
}
|
|
|
|
|
2004-05-15 14:07:44 +02:00
|
|
|
#ifndef EMBEDDED_LIBRARY
|
2004-09-02 18:16:01 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
Read date/time/datetime parameter values from network (binary
|
|
|
|
protocol). See writing counterparts of these functions in
|
|
|
|
libmysql.c (store_param_{time,date,datetime}).
|
|
|
|
*/
|
|
|
|
|
2004-05-25 00:03:49 +02:00
|
|
|
static void set_param_time(Item_param *param, uchar **pos, ulong len)
|
2003-01-24 07:32:39 +01:00
|
|
|
{
|
2004-09-02 18:16:01 +02:00
|
|
|
MYSQL_TIME tm;
|
|
|
|
ulong length= get_param_length(pos, len);
|
2003-01-24 07:32:39 +01:00
|
|
|
|
2004-09-02 18:16:01 +02:00
|
|
|
if (length >= 8)
|
2003-01-24 07:32:39 +01:00
|
|
|
{
|
|
|
|
uchar *to= *pos;
|
2004-09-02 18:16:01 +02:00
|
|
|
uint day;
|
2003-01-24 07:32:39 +01:00
|
|
|
|
2004-06-09 01:21:50 +02:00
|
|
|
tm.neg= (bool) to[0];
|
|
|
|
day= (uint) sint4korr(to+1);
|
2004-05-25 00:03:49 +02:00
|
|
|
tm.hour= (uint) to[5] + day * 24;
|
2003-01-24 07:32:39 +01:00
|
|
|
tm.minute= (uint) to[6];
|
|
|
|
tm.second= (uint) to[7];
|
2004-06-09 01:21:50 +02:00
|
|
|
tm.second_part= (length > 8) ? (ulong) sint4korr(to+8) : 0;
|
2004-05-25 00:03:49 +02:00
|
|
|
if (tm.hour > 838)
|
|
|
|
{
|
|
|
|
/* TODO: add warning 'Data truncated' here */
|
|
|
|
tm.hour= 838;
|
|
|
|
tm.minute= 59;
|
|
|
|
tm.second= 59;
|
|
|
|
}
|
|
|
|
tm.day= tm.year= tm.month= 0;
|
2003-01-24 07:32:39 +01:00
|
|
|
}
|
2004-09-02 18:16:01 +02:00
|
|
|
else
|
2004-11-15 13:44:29 +01:00
|
|
|
set_zero_time(&tm, MYSQL_TIMESTAMP_TIME);
|
2004-09-02 18:16:01 +02:00
|
|
|
param->set_time(&tm, MYSQL_TIMESTAMP_TIME,
|
|
|
|
MAX_TIME_WIDTH * MY_CHARSET_BIN_MB_MAXLEN);
|
2003-01-24 07:32:39 +01:00
|
|
|
*pos+= length;
|
|
|
|
}
|
|
|
|
|
2004-05-25 00:03:49 +02:00
|
|
|
static void set_param_datetime(Item_param *param, uchar **pos, ulong len)
|
2003-01-24 07:32:39 +01:00
|
|
|
{
|
2004-09-02 18:16:01 +02:00
|
|
|
MYSQL_TIME tm;
|
|
|
|
ulong length= get_param_length(pos, len);
|
2004-06-09 01:21:50 +02:00
|
|
|
|
2004-09-02 18:16:01 +02:00
|
|
|
if (length >= 4)
|
2003-01-24 07:32:39 +01:00
|
|
|
{
|
|
|
|
uchar *to= *pos;
|
2004-06-09 01:21:50 +02:00
|
|
|
|
|
|
|
tm.neg= 0;
|
|
|
|
tm.year= (uint) sint2korr(to);
|
|
|
|
tm.month= (uint) to[2];
|
|
|
|
tm.day= (uint) to[3];
|
2003-01-24 07:32:39 +01:00
|
|
|
if (length > 4)
|
|
|
|
{
|
|
|
|
tm.hour= (uint) to[4];
|
|
|
|
tm.minute= (uint) to[5];
|
|
|
|
tm.second= (uint) to[6];
|
|
|
|
}
|
|
|
|
else
|
|
|
|
tm.hour= tm.minute= tm.second= 0;
|
|
|
|
|
2004-06-09 01:21:50 +02:00
|
|
|
tm.second_part= (length > 7) ? (ulong) sint4korr(to+7) : 0;
|
2003-01-24 07:32:39 +01:00
|
|
|
}
|
2004-09-02 18:16:01 +02:00
|
|
|
else
|
2004-11-15 13:44:29 +01:00
|
|
|
set_zero_time(&tm, MYSQL_TIMESTAMP_DATETIME);
|
2004-09-02 18:16:01 +02:00
|
|
|
param->set_time(&tm, MYSQL_TIMESTAMP_DATETIME,
|
|
|
|
MAX_DATETIME_WIDTH * MY_CHARSET_BIN_MB_MAXLEN);
|
2003-01-24 07:32:39 +01:00
|
|
|
*pos+= length;
|
|
|
|
}
|
|
|
|
|
2004-09-09 05:59:26 +02:00
|
|
|
|
2004-05-25 00:03:49 +02:00
|
|
|
static void set_param_date(Item_param *param, uchar **pos, ulong len)
|
2003-01-24 07:32:39 +01:00
|
|
|
{
|
2004-09-02 18:16:01 +02:00
|
|
|
MYSQL_TIME tm;
|
|
|
|
ulong length= get_param_length(pos, len);
|
|
|
|
|
|
|
|
if (length >= 4)
|
2003-01-24 07:32:39 +01:00
|
|
|
{
|
|
|
|
uchar *to= *pos;
|
2004-11-15 13:44:29 +01:00
|
|
|
|
2003-01-28 18:24:27 +01:00
|
|
|
tm.year= (uint) sint2korr(to);
|
2003-01-24 07:32:39 +01:00
|
|
|
tm.month= (uint) to[2];
|
|
|
|
tm.day= (uint) to[3];
|
|
|
|
|
|
|
|
tm.hour= tm.minute= tm.second= 0;
|
|
|
|
tm.second_part= 0;
|
|
|
|
tm.neg= 0;
|
|
|
|
}
|
2004-09-02 18:16:01 +02:00
|
|
|
else
|
2004-11-15 13:44:29 +01:00
|
|
|
set_zero_time(&tm, MYSQL_TIMESTAMP_DATE);
|
2004-09-02 18:16:01 +02:00
|
|
|
param->set_time(&tm, MYSQL_TIMESTAMP_DATE,
|
|
|
|
MAX_DATE_WIDTH * MY_CHARSET_BIN_MB_MAXLEN);
|
2003-01-24 07:32:39 +01:00
|
|
|
*pos+= length;
|
|
|
|
}
|
|
|
|
|
2004-05-15 14:07:44 +02:00
|
|
|
#else/*!EMBEDDED_LIBRARY*/
|
|
|
|
void set_param_time(Item_param *param, uchar **pos, ulong len)
|
|
|
|
{
|
2004-12-02 13:08:17 +01:00
|
|
|
MYSQL_TIME tm= *((MYSQL_TIME*)*pos);
|
|
|
|
tm.hour+= tm.day * 24;
|
|
|
|
tm.day= tm.year= tm.month= 0;
|
|
|
|
if (tm.hour > 838)
|
|
|
|
{
|
|
|
|
/* TODO: add warning 'Data truncated' here */
|
|
|
|
tm.hour= 838;
|
|
|
|
tm.minute= 59;
|
|
|
|
tm.second= 59;
|
|
|
|
}
|
|
|
|
param->set_time(&tm, MYSQL_TIMESTAMP_TIME,
|
2004-05-25 00:03:49 +02:00
|
|
|
MAX_TIME_WIDTH * MY_CHARSET_BIN_MB_MAXLEN);
|
2004-05-15 14:07:44 +02:00
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
void set_param_datetime(Item_param *param, uchar **pos, ulong len)
|
|
|
|
{
|
2006-02-24 17:34:15 +01:00
|
|
|
MYSQL_TIME tm= *((MYSQL_TIME*)*pos);
|
|
|
|
tm.neg= 0;
|
2004-05-15 14:07:44 +02:00
|
|
|
|
2006-02-24 17:34:15 +01:00
|
|
|
param->set_time(&tm, MYSQL_TIMESTAMP_DATETIME,
|
2004-05-25 00:03:49 +02:00
|
|
|
MAX_DATETIME_WIDTH * MY_CHARSET_BIN_MB_MAXLEN);
|
2004-05-15 14:07:44 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
void set_param_date(Item_param *param, uchar **pos, ulong len)
|
|
|
|
{
|
|
|
|
MYSQL_TIME *to= (MYSQL_TIME*)*pos;
|
|
|
|
|
2004-06-24 17:08:36 +02:00
|
|
|
param->set_time(to, MYSQL_TIMESTAMP_DATE,
|
2004-05-25 00:03:49 +02:00
|
|
|
MAX_DATE_WIDTH * MY_CHARSET_BIN_MB_MAXLEN);
|
2004-05-15 14:07:44 +02:00
|
|
|
}
|
|
|
|
#endif /*!EMBEDDED_LIBRARY*/
|
|
|
|
|
2004-05-25 00:03:49 +02:00
|
|
|
|
|
|
|
static void set_param_str(Item_param *param, uchar **pos, ulong len)
|
2002-11-22 19:04:42 +01:00
|
|
|
{
|
2004-03-15 18:20:47 +01:00
|
|
|
ulong length= get_param_length(pos, len);
|
2004-05-25 00:03:49 +02:00
|
|
|
param->set_str((const char *)*pos, length);
|
2004-03-15 18:20:47 +01:00
|
|
|
*pos+= length;
|
2002-11-22 19:04:42 +01:00
|
|
|
}
|
|
|
|
|
2004-05-25 00:03:49 +02:00
|
|
|
|
2005-06-08 17:57:26 +02:00
|
|
|
#undef get_param_length
|
2004-05-25 00:03:49 +02:00
|
|
|
|
|
|
|
static void setup_one_conversion_function(THD *thd, Item_param *param,
|
|
|
|
uchar param_type)
|
2002-11-22 19:04:42 +01:00
|
|
|
{
|
2002-11-27 03:51:38 +01:00
|
|
|
switch (param_type) {
|
2004-05-25 00:03:49 +02:00
|
|
|
case MYSQL_TYPE_TINY:
|
2004-03-02 20:39:50 +01:00
|
|
|
param->set_param_func= set_param_tiny;
|
2004-05-25 00:03:49 +02:00
|
|
|
param->item_type= Item::INT_ITEM;
|
2003-01-28 18:24:27 +01:00
|
|
|
param->item_result_type= INT_RESULT;
|
2002-06-12 23:13:12 +02:00
|
|
|
break;
|
2004-05-25 00:03:49 +02:00
|
|
|
case MYSQL_TYPE_SHORT:
|
2004-03-02 20:39:50 +01:00
|
|
|
param->set_param_func= set_param_short;
|
2004-05-25 00:03:49 +02:00
|
|
|
param->item_type= Item::INT_ITEM;
|
2003-01-28 18:24:27 +01:00
|
|
|
param->item_result_type= INT_RESULT;
|
2002-06-12 23:13:12 +02:00
|
|
|
break;
|
2004-05-25 00:03:49 +02:00
|
|
|
case MYSQL_TYPE_LONG:
|
2004-03-02 20:39:50 +01:00
|
|
|
param->set_param_func= set_param_int32;
|
2004-05-25 00:03:49 +02:00
|
|
|
param->item_type= Item::INT_ITEM;
|
2003-01-28 18:24:27 +01:00
|
|
|
param->item_result_type= INT_RESULT;
|
2002-06-12 23:13:12 +02:00
|
|
|
break;
|
2004-05-25 00:03:49 +02:00
|
|
|
case MYSQL_TYPE_LONGLONG:
|
2004-03-02 20:39:50 +01:00
|
|
|
param->set_param_func= set_param_int64;
|
2004-05-25 00:03:49 +02:00
|
|
|
param->item_type= Item::INT_ITEM;
|
2003-01-28 18:24:27 +01:00
|
|
|
param->item_result_type= INT_RESULT;
|
2002-06-12 23:13:12 +02:00
|
|
|
break;
|
2004-05-25 00:03:49 +02:00
|
|
|
case MYSQL_TYPE_FLOAT:
|
2004-03-02 20:39:50 +01:00
|
|
|
param->set_param_func= set_param_float;
|
2004-05-25 00:03:49 +02:00
|
|
|
param->item_type= Item::REAL_ITEM;
|
2003-01-28 18:24:27 +01:00
|
|
|
param->item_result_type= REAL_RESULT;
|
2002-06-12 23:13:12 +02:00
|
|
|
break;
|
2004-05-25 00:03:49 +02:00
|
|
|
case MYSQL_TYPE_DOUBLE:
|
2004-03-02 20:39:50 +01:00
|
|
|
param->set_param_func= set_param_double;
|
2004-05-25 00:03:49 +02:00
|
|
|
param->item_type= Item::REAL_ITEM;
|
2003-01-28 18:24:27 +01:00
|
|
|
param->item_result_type= REAL_RESULT;
|
2002-06-12 23:13:12 +02:00
|
|
|
break;
|
2005-02-08 23:50:45 +01:00
|
|
|
case MYSQL_TYPE_DECIMAL:
|
|
|
|
case MYSQL_TYPE_NEWDECIMAL:
|
|
|
|
param->set_param_func= set_param_decimal;
|
|
|
|
param->item_type= Item::DECIMAL_ITEM;
|
|
|
|
param->item_result_type= DECIMAL_RESULT;
|
|
|
|
break;
|
2004-05-25 00:03:49 +02:00
|
|
|
case MYSQL_TYPE_TIME:
|
2004-03-02 20:39:50 +01:00
|
|
|
param->set_param_func= set_param_time;
|
2004-05-25 00:03:49 +02:00
|
|
|
param->item_type= Item::STRING_ITEM;
|
2003-01-28 18:24:27 +01:00
|
|
|
param->item_result_type= STRING_RESULT;
|
2003-01-24 07:32:39 +01:00
|
|
|
break;
|
2004-05-25 00:03:49 +02:00
|
|
|
case MYSQL_TYPE_DATE:
|
2004-03-02 20:39:50 +01:00
|
|
|
param->set_param_func= set_param_date;
|
2004-05-25 00:03:49 +02:00
|
|
|
param->item_type= Item::STRING_ITEM;
|
2003-01-28 18:24:27 +01:00
|
|
|
param->item_result_type= STRING_RESULT;
|
2003-01-24 07:32:39 +01:00
|
|
|
break;
|
2003-04-04 19:33:17 +02:00
|
|
|
case MYSQL_TYPE_DATETIME:
|
|
|
|
case MYSQL_TYPE_TIMESTAMP:
|
2004-03-02 20:39:50 +01:00
|
|
|
param->set_param_func= set_param_datetime;
|
2004-05-25 00:03:49 +02:00
|
|
|
param->item_type= Item::STRING_ITEM;
|
2003-01-28 18:24:27 +01:00
|
|
|
param->item_result_type= STRING_RESULT;
|
2003-01-24 07:32:39 +01:00
|
|
|
break;
|
2004-05-25 00:03:49 +02:00
|
|
|
case MYSQL_TYPE_TINY_BLOB:
|
|
|
|
case MYSQL_TYPE_MEDIUM_BLOB:
|
|
|
|
case MYSQL_TYPE_LONG_BLOB:
|
|
|
|
case MYSQL_TYPE_BLOB:
|
2004-03-02 20:39:50 +01:00
|
|
|
param->set_param_func= set_param_str;
|
2005-08-19 20:49:34 +02:00
|
|
|
param->value.cs_info.character_set_of_placeholder= &my_charset_bin;
|
|
|
|
param->value.cs_info.character_set_client=
|
|
|
|
thd->variables.character_set_client;
|
2004-05-25 00:03:49 +02:00
|
|
|
param->value.cs_info.final_character_set_of_str_value= &my_charset_bin;
|
|
|
|
param->item_type= Item::STRING_ITEM;
|
2003-01-28 18:24:27 +01:00
|
|
|
param->item_result_type= STRING_RESULT;
|
2004-05-25 00:03:49 +02:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
/*
|
|
|
|
The client library ensures that we won't get any other typecodes
|
|
|
|
except typecodes above and typecodes for string types. Marking
|
|
|
|
label as 'default' lets us to handle malformed packets as well.
|
|
|
|
*/
|
|
|
|
{
|
|
|
|
CHARSET_INFO *fromcs= thd->variables.character_set_client;
|
|
|
|
CHARSET_INFO *tocs= thd->variables.collation_connection;
|
|
|
|
uint32 dummy_offset;
|
|
|
|
|
2005-08-19 20:49:34 +02:00
|
|
|
param->value.cs_info.character_set_of_placeholder= fromcs;
|
2004-05-25 00:03:49 +02:00
|
|
|
param->value.cs_info.character_set_client= fromcs;
|
|
|
|
|
|
|
|
/*
|
|
|
|
Setup source and destination character sets so that they
|
|
|
|
are different only if conversion is necessary: this will
|
|
|
|
make later checks easier.
|
|
|
|
*/
|
|
|
|
param->value.cs_info.final_character_set_of_str_value=
|
|
|
|
String::needs_conversion(0, fromcs, tocs, &dummy_offset) ?
|
|
|
|
tocs : fromcs;
|
|
|
|
param->set_param_func= set_param_str;
|
|
|
|
/*
|
|
|
|
Exact value of max_length is not known unless data is converted to
|
|
|
|
charset of connection, so we have to set it later.
|
|
|
|
*/
|
|
|
|
param->item_type= Item::STRING_ITEM;
|
|
|
|
param->item_result_type= STRING_RESULT;
|
|
|
|
}
|
2002-06-12 23:13:12 +02:00
|
|
|
}
|
2004-06-09 01:21:50 +02:00
|
|
|
param->param_type= (enum enum_field_types) param_type;
|
2002-06-12 23:13:12 +02:00
|
|
|
}
|
|
|
|
|
2003-09-17 17:48:53 +02:00
|
|
|
#ifndef EMBEDDED_LIBRARY
|
2002-06-12 23:13:12 +02:00
|
|
|
/*
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
Routines to assign parameters from data supplied by the client.
|
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
Update the parameter markers by reading data from the packet and
|
|
|
|
and generate a valid query for logging.
|
|
|
|
|
|
|
|
NOTES
|
|
|
|
This function, along with other _withlog functions is called when one of
|
|
|
|
binary, slow or general logs is open. Logging of prepared statements in
|
|
|
|
all cases is performed by means of conventional queries: if parameter
|
|
|
|
data was supplied from C API, each placeholder in the query is
|
|
|
|
replaced with its actual value; if we're logging a [Dynamic] SQL
|
|
|
|
prepared statement, parameter markers are replaced with variable names.
|
|
|
|
Example:
|
|
|
|
mysql_stmt_prepare("UPDATE t1 SET a=a*1.25 WHERE a=?")
|
|
|
|
--> general logs gets [Prepare] UPDATE t1 SET a*1.25 WHERE a=?"
|
|
|
|
mysql_stmt_execute(stmt);
|
|
|
|
--> general and binary logs get
|
|
|
|
[Execute] UPDATE t1 SET a*1.25 WHERE a=1"
|
|
|
|
If a statement has been prepared using SQL syntax:
|
|
|
|
PREPARE stmt FROM "UPDATE t1 SET a=a*1.25 WHERE a=?"
|
|
|
|
--> general log gets
|
|
|
|
[Query] PREPARE stmt FROM "UPDATE ..."
|
|
|
|
EXECUTE stmt USING @a
|
|
|
|
--> general log gets
|
|
|
|
[Query] EXECUTE stmt USING @a;
|
|
|
|
|
|
|
|
RETURN VALUE
|
|
|
|
0 if success, 1 otherwise
|
2002-06-12 23:13:12 +02:00
|
|
|
*/
|
|
|
|
|
2004-03-15 18:20:47 +01:00
|
|
|
static bool insert_params_withlog(Prepared_statement *stmt, uchar *null_array,
|
2005-06-08 17:57:26 +02:00
|
|
|
uchar *read_pos, uchar *data_end,
|
2004-05-24 19:08:22 +02:00
|
|
|
String *query)
|
2003-04-04 19:33:17 +02:00
|
|
|
{
|
2004-03-02 20:39:50 +01:00
|
|
|
THD *thd= stmt->thd;
|
|
|
|
Item_param **begin= stmt->param_array;
|
|
|
|
Item_param **end= begin + stmt->param_count;
|
|
|
|
uint32 length= 0;
|
2005-06-08 17:57:26 +02:00
|
|
|
String str;
|
2003-12-20 00:16:10 +01:00
|
|
|
const String *res;
|
2005-06-08 17:57:26 +02:00
|
|
|
DBUG_ENTER("insert_params_withlog");
|
2003-11-27 17:14:16 +01:00
|
|
|
|
2004-05-24 19:08:22 +02:00
|
|
|
if (query->copy(stmt->query, stmt->query_length, default_charset_info))
|
2003-11-27 17:14:16 +01:00
|
|
|
DBUG_RETURN(1);
|
2005-06-08 17:57:26 +02:00
|
|
|
|
2004-03-02 20:39:50 +01:00
|
|
|
for (Item_param **it= begin; it < end; ++it)
|
2003-04-04 19:33:17 +02:00
|
|
|
{
|
2004-03-02 20:39:50 +01:00
|
|
|
Item_param *param= *it;
|
2004-05-25 00:03:49 +02:00
|
|
|
if (param->state != Item_param::LONG_DATA_VALUE)
|
2003-04-04 19:33:17 +02:00
|
|
|
{
|
2004-03-15 18:20:47 +01:00
|
|
|
if (is_param_null(null_array, it - begin))
|
2004-05-04 17:08:19 +02:00
|
|
|
param->set_null();
|
2003-04-04 19:33:17 +02:00
|
|
|
else
|
|
|
|
{
|
2004-03-15 18:20:47 +01:00
|
|
|
if (read_pos >= data_end)
|
|
|
|
DBUG_RETURN(1);
|
|
|
|
param->set_param_func(param, &read_pos, data_end - read_pos);
|
2003-04-04 19:33:17 +02:00
|
|
|
}
|
|
|
|
}
|
2004-05-25 00:03:49 +02:00
|
|
|
res= param->query_val_str(&str);
|
|
|
|
if (param->convert_str_value(thd))
|
|
|
|
DBUG_RETURN(1); /* out of memory */
|
|
|
|
|
2004-05-24 19:08:22 +02:00
|
|
|
if (query->replace(param->pos_in_query+length, 1, *res))
|
2003-04-04 19:33:17 +02:00
|
|
|
DBUG_RETURN(1);
|
2005-06-08 17:57:26 +02:00
|
|
|
|
2003-04-04 19:33:17 +02:00
|
|
|
length+= res->length()-1;
|
|
|
|
}
|
|
|
|
DBUG_RETURN(0);
|
|
|
|
}
|
|
|
|
|
2003-12-20 00:16:10 +01:00
|
|
|
|
2004-03-15 18:20:47 +01:00
|
|
|
static bool insert_params(Prepared_statement *stmt, uchar *null_array,
|
2005-06-08 17:57:26 +02:00
|
|
|
uchar *read_pos, uchar *data_end,
|
2004-05-24 19:08:22 +02:00
|
|
|
String *expanded_query)
|
2003-04-04 19:33:17 +02:00
|
|
|
{
|
2004-03-02 20:39:50 +01:00
|
|
|
Item_param **begin= stmt->param_array;
|
|
|
|
Item_param **end= begin + stmt->param_count;
|
2003-12-20 00:16:10 +01:00
|
|
|
|
2005-06-08 17:57:26 +02:00
|
|
|
DBUG_ENTER("insert_params");
|
2003-12-20 00:16:10 +01:00
|
|
|
|
2004-03-02 20:39:50 +01:00
|
|
|
for (Item_param **it= begin; it < end; ++it)
|
2003-04-04 19:33:17 +02:00
|
|
|
{
|
2004-03-02 20:39:50 +01:00
|
|
|
Item_param *param= *it;
|
2004-05-25 00:03:49 +02:00
|
|
|
if (param->state != Item_param::LONG_DATA_VALUE)
|
2003-04-04 19:33:17 +02:00
|
|
|
{
|
2004-03-15 18:20:47 +01:00
|
|
|
if (is_param_null(null_array, it - begin))
|
2004-05-04 17:08:19 +02:00
|
|
|
param->set_null();
|
2003-04-04 19:33:17 +02:00
|
|
|
else
|
|
|
|
{
|
2004-03-15 18:20:47 +01:00
|
|
|
if (read_pos >= data_end)
|
|
|
|
DBUG_RETURN(1);
|
|
|
|
param->set_param_func(param, &read_pos, data_end - read_pos);
|
2003-04-04 19:33:17 +02:00
|
|
|
}
|
|
|
|
}
|
2004-05-25 00:03:49 +02:00
|
|
|
if (param->convert_str_value(stmt->thd))
|
|
|
|
DBUG_RETURN(1); /* out of memory */
|
2003-04-04 19:33:17 +02:00
|
|
|
}
|
|
|
|
DBUG_RETURN(0);
|
|
|
|
}
|
|
|
|
|
2002-10-02 12:33:08 +02:00
|
|
|
|
2004-03-02 20:39:50 +01:00
|
|
|
static bool setup_conversion_functions(Prepared_statement *stmt,
|
2004-03-15 18:20:47 +01:00
|
|
|
uchar **data, uchar *data_end)
|
2004-03-02 20:39:50 +01:00
|
|
|
{
|
|
|
|
/* skip null bits */
|
|
|
|
uchar *read_pos= *data + (stmt->param_count+7) / 8;
|
2002-06-12 23:13:12 +02:00
|
|
|
|
2004-03-02 20:39:50 +01:00
|
|
|
DBUG_ENTER("setup_conversion_functions");
|
2003-12-20 00:16:10 +01:00
|
|
|
|
2002-11-22 19:04:42 +01:00
|
|
|
if (*read_pos++) //types supplied / first execute
|
2004-03-02 20:39:50 +01:00
|
|
|
{
|
2002-11-22 19:04:42 +01:00
|
|
|
/*
|
2005-06-08 17:57:26 +02:00
|
|
|
First execute or types altered by the client, setup the
|
2002-11-22 19:04:42 +01:00
|
|
|
conversion routines for all parameters (one time)
|
|
|
|
*/
|
2004-03-02 20:39:50 +01:00
|
|
|
Item_param **it= stmt->param_array;
|
|
|
|
Item_param **end= it + stmt->param_count;
|
2004-05-25 00:03:49 +02:00
|
|
|
THD *thd= stmt->thd;
|
2004-03-02 20:39:50 +01:00
|
|
|
for (; it < end; ++it)
|
|
|
|
{
|
2004-04-30 01:00:19 +02:00
|
|
|
ushort typecode;
|
|
|
|
const uint signed_bit= 1 << 15;
|
|
|
|
|
2004-03-15 18:20:47 +01:00
|
|
|
if (read_pos >= data_end)
|
|
|
|
DBUG_RETURN(1);
|
2004-04-30 01:00:19 +02:00
|
|
|
|
|
|
|
typecode= sint2korr(read_pos);
|
2002-12-07 08:39:11 +01:00
|
|
|
read_pos+= 2;
|
2004-04-30 01:00:19 +02:00
|
|
|
(**it).unsigned_flag= test(typecode & signed_bit);
|
2004-05-25 00:03:49 +02:00
|
|
|
setup_one_conversion_function(thd, *it, (uchar) (typecode & ~signed_bit));
|
2002-06-12 23:13:12 +02:00
|
|
|
}
|
2004-03-02 20:39:50 +01:00
|
|
|
}
|
|
|
|
*data= read_pos;
|
2002-06-12 23:13:12 +02:00
|
|
|
DBUG_RETURN(0);
|
|
|
|
}
|
|
|
|
|
2003-12-20 00:16:10 +01:00
|
|
|
#else
|
|
|
|
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
/*
|
|
|
|
Embedded counterparts of parameter assignment routines.
|
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
The main difference between the embedded library and the server is
|
|
|
|
that in embedded case we don't serialize/deserialize parameters data.
|
|
|
|
Additionally, for unknown reason, the client-side flag raised for
|
|
|
|
changed types of placeholders is ignored and we simply setup conversion
|
|
|
|
functions at each execute (TODO: fix).
|
|
|
|
*/
|
|
|
|
|
2004-05-24 19:08:22 +02:00
|
|
|
static bool emb_insert_params(Prepared_statement *stmt, String *expanded_query)
|
2004-03-02 20:39:50 +01:00
|
|
|
{
|
2004-05-25 00:03:49 +02:00
|
|
|
THD *thd= stmt->thd;
|
2004-03-02 20:39:50 +01:00
|
|
|
Item_param **it= stmt->param_array;
|
|
|
|
Item_param **end= it + stmt->param_count;
|
2003-12-20 00:16:10 +01:00
|
|
|
MYSQL_BIND *client_param= stmt->thd->client_params;
|
|
|
|
|
2004-03-02 20:39:50 +01:00
|
|
|
DBUG_ENTER("emb_insert_params");
|
2003-12-20 00:16:10 +01:00
|
|
|
|
2004-03-02 20:39:50 +01:00
|
|
|
for (; it < end; ++it, ++client_param)
|
|
|
|
{
|
|
|
|
Item_param *param= *it;
|
2004-05-25 00:03:49 +02:00
|
|
|
setup_one_conversion_function(thd, param, client_param->buffer_type);
|
|
|
|
if (param->state != Item_param::LONG_DATA_VALUE)
|
2003-12-20 00:16:10 +01:00
|
|
|
{
|
|
|
|
if (*client_param->is_null)
|
2004-05-04 17:08:19 +02:00
|
|
|
param->set_null();
|
2003-12-20 00:16:10 +01:00
|
|
|
else
|
|
|
|
{
|
2004-05-25 00:03:49 +02:00
|
|
|
uchar *buff= (uchar*) client_param->buffer;
|
2004-08-19 12:38:12 +02:00
|
|
|
param->unsigned_flag= client_param->is_unsigned;
|
2004-03-02 20:39:50 +01:00
|
|
|
param->set_param_func(param, &buff,
|
2005-06-08 17:57:26 +02:00
|
|
|
client_param->length ?
|
|
|
|
*client_param->length :
|
2004-03-02 20:39:50 +01:00
|
|
|
client_param->buffer_length);
|
2003-12-20 00:16:10 +01:00
|
|
|
}
|
|
|
|
}
|
2004-05-25 00:03:49 +02:00
|
|
|
if (param->convert_str_value(thd))
|
|
|
|
DBUG_RETURN(1); /* out of memory */
|
2003-12-20 00:16:10 +01:00
|
|
|
}
|
|
|
|
DBUG_RETURN(0);
|
|
|
|
}
|
|
|
|
|
2004-03-02 20:39:50 +01:00
|
|
|
|
2004-05-24 19:08:22 +02:00
|
|
|
static bool emb_insert_params_withlog(Prepared_statement *stmt, String *query)
|
2004-03-02 20:39:50 +01:00
|
|
|
{
|
2003-12-20 00:16:10 +01:00
|
|
|
THD *thd= stmt->thd;
|
2004-03-02 20:39:50 +01:00
|
|
|
Item_param **it= stmt->param_array;
|
|
|
|
Item_param **end= it + stmt->param_count;
|
2003-12-20 00:16:10 +01:00
|
|
|
MYSQL_BIND *client_param= thd->client_params;
|
|
|
|
|
2004-05-24 19:08:22 +02:00
|
|
|
String str;
|
2003-12-20 00:16:10 +01:00
|
|
|
const String *res;
|
2004-03-02 20:39:50 +01:00
|
|
|
uint32 length= 0;
|
2003-12-20 00:16:10 +01:00
|
|
|
|
2004-03-02 20:39:50 +01:00
|
|
|
DBUG_ENTER("emb_insert_params_withlog");
|
2003-12-20 00:16:10 +01:00
|
|
|
|
2004-05-24 19:08:22 +02:00
|
|
|
if (query->copy(stmt->query, stmt->query_length, default_charset_info))
|
2003-12-20 00:16:10 +01:00
|
|
|
DBUG_RETURN(1);
|
2005-06-08 17:57:26 +02:00
|
|
|
|
2004-03-02 20:39:50 +01:00
|
|
|
for (; it < end; ++it, ++client_param)
|
|
|
|
{
|
|
|
|
Item_param *param= *it;
|
2004-05-25 00:03:49 +02:00
|
|
|
setup_one_conversion_function(thd, param, client_param->buffer_type);
|
|
|
|
if (param->state != Item_param::LONG_DATA_VALUE)
|
2003-12-20 00:16:10 +01:00
|
|
|
{
|
|
|
|
if (*client_param->is_null)
|
2004-05-04 17:08:19 +02:00
|
|
|
param->set_null();
|
2003-12-20 00:16:10 +01:00
|
|
|
else
|
|
|
|
{
|
2004-05-25 00:03:49 +02:00
|
|
|
uchar *buff= (uchar*)client_param->buffer;
|
2005-06-08 17:57:26 +02:00
|
|
|
param->unsigned_flag= client_param->is_unsigned;
|
2004-03-02 20:39:50 +01:00
|
|
|
param->set_param_func(param, &buff,
|
2005-06-08 17:57:26 +02:00
|
|
|
client_param->length ?
|
|
|
|
*client_param->length :
|
2004-03-02 20:39:50 +01:00
|
|
|
client_param->buffer_length);
|
2003-12-20 00:16:10 +01:00
|
|
|
}
|
|
|
|
}
|
2004-06-01 15:27:40 +02:00
|
|
|
res= param->query_val_str(&str);
|
|
|
|
if (param->convert_str_value(thd))
|
|
|
|
DBUG_RETURN(1); /* out of memory */
|
|
|
|
|
2004-05-24 19:08:22 +02:00
|
|
|
if (query->replace(param->pos_in_query+length, 1, *res))
|
2003-12-20 00:16:10 +01:00
|
|
|
DBUG_RETURN(1);
|
2004-06-07 10:09:10 +02:00
|
|
|
|
2003-12-20 00:16:10 +01:00
|
|
|
length+= res->length()-1;
|
|
|
|
}
|
|
|
|
DBUG_RETURN(0);
|
|
|
|
}
|
|
|
|
|
2003-09-17 17:48:53 +02:00
|
|
|
#endif /*!EMBEDDED_LIBRARY*/
|
|
|
|
|
2004-04-10 00:14:32 +02:00
|
|
|
|
2004-06-07 10:09:10 +02:00
|
|
|
/*
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
Assign prepared statement parameters from user variables.
|
|
|
|
|
2004-04-05 17:43:37 +02:00
|
|
|
SYNOPSIS
|
|
|
|
insert_params_from_vars()
|
|
|
|
stmt Statement
|
|
|
|
varnames List of variables. Caller must ensure that number of variables
|
|
|
|
in the list is equal to number of statement parameters
|
2004-05-24 19:08:22 +02:00
|
|
|
query Ignored
|
2004-04-05 17:43:37 +02:00
|
|
|
*/
|
|
|
|
|
2004-06-07 10:09:10 +02:00
|
|
|
static bool insert_params_from_vars(Prepared_statement *stmt,
|
|
|
|
List<LEX_STRING>& varnames,
|
2004-05-24 19:08:22 +02:00
|
|
|
String *query __attribute__((unused)))
|
2004-04-05 17:43:37 +02:00
|
|
|
{
|
|
|
|
Item_param **begin= stmt->param_array;
|
|
|
|
Item_param **end= begin + stmt->param_count;
|
|
|
|
user_var_entry *entry;
|
|
|
|
LEX_STRING *varname;
|
|
|
|
List_iterator<LEX_STRING> var_it(varnames);
|
2004-06-07 10:09:10 +02:00
|
|
|
DBUG_ENTER("insert_params_from_vars");
|
|
|
|
|
2004-04-05 17:43:37 +02:00
|
|
|
for (Item_param **it= begin; it < end; ++it)
|
|
|
|
{
|
|
|
|
Item_param *param= *it;
|
|
|
|
varname= var_it++;
|
2004-06-07 10:09:10 +02:00
|
|
|
entry= (user_var_entry*)hash_search(&stmt->thd->user_vars,
|
|
|
|
(byte*) varname->str,
|
|
|
|
varname->length);
|
|
|
|
if (param->set_from_user_var(stmt->thd, entry) ||
|
|
|
|
param->convert_str_value(stmt->thd))
|
|
|
|
DBUG_RETURN(1);
|
2004-04-05 17:43:37 +02:00
|
|
|
}
|
|
|
|
DBUG_RETURN(0);
|
|
|
|
}
|
|
|
|
|
2004-05-24 19:08:22 +02:00
|
|
|
|
2004-06-07 10:09:10 +02:00
|
|
|
/*
|
2004-05-24 19:08:22 +02:00
|
|
|
Do the same as insert_params_from_vars but also construct query text for
|
|
|
|
binary log.
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
|
2004-05-24 19:08:22 +02:00
|
|
|
SYNOPSIS
|
|
|
|
insert_params_from_vars()
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
stmt Prepared statement
|
2004-05-24 19:08:22 +02:00
|
|
|
varnames List of variables. Caller must ensure that number of variables
|
|
|
|
in the list is equal to number of statement parameters
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
query The query with parameter markers replaced with corresponding
|
|
|
|
user variables that were used to execute the query.
|
2004-05-24 19:08:22 +02:00
|
|
|
*/
|
|
|
|
|
2004-04-05 17:43:37 +02:00
|
|
|
static bool insert_params_from_vars_with_log(Prepared_statement *stmt,
|
2004-06-07 10:09:10 +02:00
|
|
|
List<LEX_STRING>& varnames,
|
2004-05-24 19:08:22 +02:00
|
|
|
String *query)
|
2004-04-05 17:43:37 +02:00
|
|
|
{
|
|
|
|
Item_param **begin= stmt->param_array;
|
|
|
|
Item_param **end= begin + stmt->param_count;
|
|
|
|
user_var_entry *entry;
|
|
|
|
LEX_STRING *varname;
|
|
|
|
List_iterator<LEX_STRING> var_it(varnames);
|
2005-06-16 22:11:48 +02:00
|
|
|
String buf;
|
|
|
|
const String *val;
|
2004-04-05 17:43:37 +02:00
|
|
|
uint32 length= 0;
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
|
|
|
|
DBUG_ENTER("insert_params_from_vars");
|
|
|
|
|
2004-05-24 19:08:22 +02:00
|
|
|
if (query->copy(stmt->query, stmt->query_length, default_charset_info))
|
2004-04-12 23:58:48 +02:00
|
|
|
DBUG_RETURN(1);
|
2004-04-05 17:43:37 +02:00
|
|
|
|
|
|
|
for (Item_param **it= begin; it < end; ++it)
|
|
|
|
{
|
|
|
|
Item_param *param= *it;
|
|
|
|
varname= var_it++;
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
if (get_var_with_binlog(stmt->thd, stmt->lex->sql_command,
|
|
|
|
*varname, &entry))
|
2004-06-01 15:27:40 +02:00
|
|
|
DBUG_RETURN(1);
|
2004-04-05 17:43:37 +02:00
|
|
|
|
2004-06-07 10:09:10 +02:00
|
|
|
if (param->set_from_user_var(stmt->thd, entry))
|
|
|
|
DBUG_RETURN(1);
|
|
|
|
/* Insert @'escaped-varname' instead of parameter in the query */
|
2005-06-16 22:11:48 +02:00
|
|
|
if (entry)
|
|
|
|
{
|
|
|
|
char *begin, *ptr;
|
|
|
|
buf.length(0);
|
|
|
|
if (buf.reserve(entry->name.length*2+3))
|
|
|
|
DBUG_RETURN(1);
|
2004-06-01 15:27:40 +02:00
|
|
|
|
2005-06-16 22:11:48 +02:00
|
|
|
begin= ptr= buf.c_ptr_quick();
|
|
|
|
*ptr++= '@';
|
|
|
|
*ptr++= '\'';
|
|
|
|
ptr+= escape_string_for_mysql(&my_charset_utf8_general_ci,
|
2005-06-16 22:34:35 +02:00
|
|
|
ptr, 0, entry->name.str,
|
|
|
|
entry->name.length);
|
2005-06-16 22:11:48 +02:00
|
|
|
*ptr++= '\'';
|
|
|
|
buf.length(ptr - begin);
|
|
|
|
val= &buf;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
val= &my_null_string;
|
2004-06-01 15:27:40 +02:00
|
|
|
|
|
|
|
if (param->convert_str_value(stmt->thd))
|
|
|
|
DBUG_RETURN(1); /* out of memory */
|
2004-06-07 10:09:10 +02:00
|
|
|
|
2005-06-16 22:11:48 +02:00
|
|
|
if (query->replace(param->pos_in_query+length, 1, *val))
|
2004-06-01 15:27:40 +02:00
|
|
|
DBUG_RETURN(1);
|
2005-06-16 22:11:48 +02:00
|
|
|
length+= val->length()-1;
|
2004-04-05 17:43:37 +02:00
|
|
|
}
|
|
|
|
DBUG_RETURN(0);
|
|
|
|
}
|
|
|
|
|
2002-06-12 23:13:12 +02:00
|
|
|
/*
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
Validate INSERT statement.
|
2004-04-10 00:14:32 +02:00
|
|
|
|
2004-03-02 20:39:50 +01:00
|
|
|
SYNOPSIS
|
2004-04-10 00:14:32 +02:00
|
|
|
mysql_test_insert()
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
stmt prepared statement
|
|
|
|
tables global/local table list
|
2004-04-10 00:14:32 +02:00
|
|
|
|
2004-03-02 20:39:50 +01:00
|
|
|
RETURN VALUE
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
FALSE success
|
|
|
|
TRUE error, error message is set in THD
|
2002-06-12 23:13:12 +02:00
|
|
|
*/
|
2004-09-09 06:26:28 +02:00
|
|
|
|
2004-10-20 03:04:37 +02:00
|
|
|
static bool mysql_test_insert(Prepared_statement *stmt,
|
|
|
|
TABLE_LIST *table_list,
|
2005-06-08 17:57:26 +02:00
|
|
|
List<Item> &fields,
|
2004-10-20 03:04:37 +02:00
|
|
|
List<List_item> &values_list,
|
|
|
|
List<Item> &update_fields,
|
|
|
|
List<Item> &update_values,
|
|
|
|
enum_duplicates duplic)
|
2002-06-12 23:13:12 +02:00
|
|
|
{
|
2002-10-02 12:33:08 +02:00
|
|
|
THD *thd= stmt->thd;
|
2004-04-07 23:16:17 +02:00
|
|
|
LEX *lex= stmt->lex;
|
2002-06-12 23:13:12 +02:00
|
|
|
List_iterator_fast<List_item> its(values_list);
|
|
|
|
List_item *values;
|
2004-05-25 00:03:49 +02:00
|
|
|
DBUG_ENTER("mysql_test_insert");
|
2002-06-12 23:13:12 +02:00
|
|
|
|
2005-06-08 17:31:34 +02:00
|
|
|
if (insert_precheck(thd, table_list))
|
|
|
|
goto error;
|
2004-02-20 14:37:45 +01:00
|
|
|
|
2004-04-07 23:16:17 +02:00
|
|
|
/*
|
2005-07-04 02:24:25 +02:00
|
|
|
open temporary memory pool for temporary data allocated by derived
|
|
|
|
tables & preparation procedure
|
|
|
|
Note that this is done without locks (should not be needed as we will not
|
|
|
|
access any data here)
|
|
|
|
If we would use locks, then we have to ensure we are not using
|
|
|
|
TL_WRITE_DELAYED as having two such locks can cause table corruption.
|
2004-02-20 14:37:45 +01:00
|
|
|
*/
|
2005-08-08 15:46:06 +02:00
|
|
|
if (open_normal_and_derived_tables(thd, table_list, 0))
|
2005-06-08 17:31:34 +02:00
|
|
|
goto error;
|
2005-01-05 16:42:22 +01:00
|
|
|
|
2002-06-12 23:13:12 +02:00
|
|
|
if ((values= its++))
|
|
|
|
{
|
|
|
|
uint value_count;
|
2002-10-02 12:33:08 +02:00
|
|
|
ulong counter= 0;
|
2004-12-30 23:44:00 +01:00
|
|
|
Item *unused_conds= 0;
|
2002-06-12 23:13:12 +02:00
|
|
|
|
2004-12-31 17:59:43 +01:00
|
|
|
if (table_list->table)
|
2005-01-03 12:56:23 +01:00
|
|
|
{
|
|
|
|
// don't allocate insert_values
|
|
|
|
table_list->table->insert_values=(byte *)1;
|
|
|
|
}
|
|
|
|
|
2005-07-04 02:24:25 +02:00
|
|
|
if (mysql_prepare_insert(thd, table_list, table_list->table,
|
|
|
|
fields, values, update_fields, update_values,
|
|
|
|
duplic, &unused_conds, FALSE))
|
2004-04-10 00:14:32 +02:00
|
|
|
goto error;
|
2004-12-24 23:30:40 +01:00
|
|
|
|
2002-06-12 23:13:12 +02:00
|
|
|
value_count= values->elements;
|
|
|
|
its.rewind();
|
2004-12-24 23:30:40 +01:00
|
|
|
|
2005-01-05 16:42:22 +01:00
|
|
|
if (table_list->lock_type == TL_WRITE_DELAYED &&
|
|
|
|
!(table_list->table->file->table_flags() & HA_CAN_INSERT_DELAYED))
|
|
|
|
{
|
|
|
|
my_error(ER_ILLEGAL_HA, MYF(0), (table_list->view ?
|
|
|
|
table_list->view_name.str :
|
2005-01-06 15:59:29 +01:00
|
|
|
table_list->table_name));
|
2005-01-05 16:42:22 +01:00
|
|
|
goto error;
|
|
|
|
}
|
2002-10-02 12:33:08 +02:00
|
|
|
while ((values= its++))
|
2002-06-12 23:13:12 +02:00
|
|
|
{
|
|
|
|
counter++;
|
|
|
|
if (values->elements != value_count)
|
|
|
|
{
|
2004-11-13 18:35:51 +01:00
|
|
|
my_error(ER_WRONG_VALUE_COUNT_ON_ROW, MYF(0), counter);
|
2004-04-07 23:16:17 +02:00
|
|
|
goto error;
|
2002-06-12 23:13:12 +02:00
|
|
|
}
|
2005-07-01 06:05:42 +02:00
|
|
|
if (setup_fields(thd, 0, *values, 0, 0, 0))
|
2005-06-08 17:57:26 +02:00
|
|
|
goto error;
|
2002-06-12 23:13:12 +02:00
|
|
|
}
|
|
|
|
}
|
2005-06-08 17:31:34 +02:00
|
|
|
DBUG_RETURN(FALSE);
|
2004-04-07 23:16:17 +02:00
|
|
|
|
|
|
|
error:
|
2005-01-03 12:56:23 +01:00
|
|
|
/* insert_values is cleared in open_table */
|
2005-06-08 17:31:34 +02:00
|
|
|
DBUG_RETURN(TRUE);
|
2002-06-12 23:13:12 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
2004-04-10 00:14:32 +02:00
|
|
|
Validate UPDATE statement
|
|
|
|
|
2004-03-02 20:39:50 +01:00
|
|
|
SYNOPSIS
|
2004-05-25 00:03:49 +02:00
|
|
|
mysql_test_update()
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
stmt prepared statement
|
|
|
|
tables list of tables used in this query
|
2004-04-10 00:14:32 +02:00
|
|
|
|
2004-03-02 20:39:50 +01:00
|
|
|
RETURN VALUE
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
0 success
|
|
|
|
1 error, error message is set in THD
|
|
|
|
2 convert to multi_update
|
2002-06-12 23:13:12 +02:00
|
|
|
*/
|
2005-06-08 17:31:34 +02:00
|
|
|
|
2004-04-10 00:14:32 +02:00
|
|
|
static int mysql_test_update(Prepared_statement *stmt,
|
2004-10-20 03:04:37 +02:00
|
|
|
TABLE_LIST *table_list)
|
2002-06-12 23:13:12 +02:00
|
|
|
{
|
2004-04-10 00:14:32 +02:00
|
|
|
int res;
|
2002-10-02 12:33:08 +02:00
|
|
|
THD *thd= stmt->thd;
|
2004-11-25 01:23:13 +01:00
|
|
|
uint table_count= 0;
|
2004-04-10 00:14:32 +02:00
|
|
|
SELECT_LEX *select= &stmt->lex->select_lex;
|
2005-01-04 17:04:16 +01:00
|
|
|
#ifndef NO_EMBEDDED_ACCESS_CHECKS
|
2005-06-08 17:57:26 +02:00
|
|
|
uint want_privilege;
|
2005-01-04 17:04:16 +01:00
|
|
|
#endif
|
2005-09-15 01:56:09 +02:00
|
|
|
bool need_reopen;
|
2004-04-10 00:14:32 +02:00
|
|
|
DBUG_ENTER("mysql_test_update");
|
|
|
|
|
2004-11-21 19:08:12 +01:00
|
|
|
if (update_precheck(thd, table_list))
|
2005-06-08 17:31:34 +02:00
|
|
|
goto error;
|
|
|
|
|
2005-09-15 01:56:09 +02:00
|
|
|
for ( ; ; )
|
2004-02-12 17:50:00 +01:00
|
|
|
{
|
2005-09-15 01:56:09 +02:00
|
|
|
if (open_tables(thd, &table_list, &table_count, 0))
|
|
|
|
goto error;
|
|
|
|
|
|
|
|
if (table_list->multitable_view)
|
|
|
|
{
|
|
|
|
DBUG_ASSERT(table_list->view != 0);
|
|
|
|
DBUG_PRINT("info", ("Switch to multi-update"));
|
|
|
|
/* pass counter value */
|
|
|
|
thd->lex->table_count= table_count;
|
|
|
|
/* convert to multiupdate */
|
|
|
|
DBUG_RETURN(2);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!lock_tables(thd, table_list, table_count, &need_reopen))
|
|
|
|
break;
|
|
|
|
if (!need_reopen)
|
|
|
|
goto error;
|
2006-02-16 14:19:24 +01:00
|
|
|
close_tables_for_reopen(thd, &table_list);
|
2005-06-08 17:31:34 +02:00
|
|
|
}
|
2004-11-25 01:23:13 +01:00
|
|
|
|
2005-06-08 17:31:34 +02:00
|
|
|
/*
|
|
|
|
thd->fill_derived_tables() is false here for sure (because it is
|
|
|
|
preparation of PS, so we even do not check it).
|
|
|
|
*/
|
2005-09-15 01:56:09 +02:00
|
|
|
if (mysql_handle_derived(thd->lex, &mysql_derived_prepare))
|
2005-06-08 17:31:34 +02:00
|
|
|
goto error;
|
2004-11-25 01:23:13 +01:00
|
|
|
|
2005-01-04 17:04:16 +01:00
|
|
|
#ifndef NO_EMBEDDED_ACCESS_CHECKS
|
|
|
|
/* TABLE_LIST contain right privilages request */
|
|
|
|
want_privilege= table_list->grant.want_privilege;
|
|
|
|
#endif
|
|
|
|
|
2005-06-08 17:31:34 +02:00
|
|
|
if (mysql_prepare_update(thd, table_list, &select->where,
|
|
|
|
select->order_list.elements,
|
|
|
|
(ORDER *) select->order_list.first))
|
|
|
|
goto error;
|
|
|
|
|
2005-01-04 17:04:16 +01:00
|
|
|
#ifndef NO_EMBEDDED_ACCESS_CHECKS
|
2005-06-08 17:31:34 +02:00
|
|
|
table_list->grant.want_privilege= want_privilege;
|
|
|
|
table_list->table->grant.want_privilege= want_privilege;
|
2005-10-27 23:18:23 +02:00
|
|
|
table_list->register_want_access(want_privilege);
|
2005-01-04 17:04:16 +01:00
|
|
|
#endif
|
2005-07-01 06:05:42 +02:00
|
|
|
thd->lex->select_lex.no_wrap_view_item= TRUE;
|
|
|
|
res= setup_fields(thd, 0, select->item_list, 1, 0, 0);
|
|
|
|
thd->lex->select_lex.no_wrap_view_item= FALSE;
|
2005-06-08 17:31:34 +02:00
|
|
|
if (res)
|
|
|
|
goto error;
|
2005-01-04 17:04:16 +01:00
|
|
|
#ifndef NO_EMBEDDED_ACCESS_CHECKS
|
2005-06-08 17:31:34 +02:00
|
|
|
/* Check values */
|
|
|
|
table_list->grant.want_privilege=
|
|
|
|
table_list->table->grant.want_privilege=
|
|
|
|
(SELECT_ACL & ~table_list->table->grant.privilege);
|
2005-10-27 23:18:23 +02:00
|
|
|
table_list->register_want_access(SELECT_ACL);
|
2005-01-04 17:04:16 +01:00
|
|
|
#endif
|
2005-07-01 06:05:42 +02:00
|
|
|
if (setup_fields(thd, 0, stmt->lex->value_list, 0, 0, 0))
|
2005-06-08 17:31:34 +02:00
|
|
|
goto error;
|
2005-06-08 17:57:26 +02:00
|
|
|
/* TODO: here we should send types of placeholders to the client. */
|
2005-06-08 17:31:34 +02:00
|
|
|
DBUG_RETURN(0);
|
|
|
|
error:
|
|
|
|
DBUG_RETURN(1);
|
2002-06-12 23:13:12 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
Validate DELETE statement.
|
2004-04-10 00:14:32 +02:00
|
|
|
|
2004-03-02 20:39:50 +01:00
|
|
|
SYNOPSIS
|
2004-04-10 00:14:32 +02:00
|
|
|
mysql_test_delete()
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
stmt prepared statement
|
|
|
|
tables list of tables used in this query
|
2004-04-10 00:14:32 +02:00
|
|
|
|
2004-03-02 20:39:50 +01:00
|
|
|
RETURN VALUE
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
FALSE success
|
|
|
|
TRUE error, error message is set in THD
|
2002-06-12 23:13:12 +02:00
|
|
|
*/
|
2005-06-08 17:31:34 +02:00
|
|
|
|
|
|
|
static bool mysql_test_delete(Prepared_statement *stmt,
|
|
|
|
TABLE_LIST *table_list)
|
2002-06-12 23:13:12 +02:00
|
|
|
{
|
2002-10-02 12:33:08 +02:00
|
|
|
THD *thd= stmt->thd;
|
2004-04-10 00:14:32 +02:00
|
|
|
LEX *lex= stmt->lex;
|
|
|
|
DBUG_ENTER("mysql_test_delete");
|
2002-06-12 23:13:12 +02:00
|
|
|
|
2005-06-08 17:31:34 +02:00
|
|
|
if (delete_precheck(thd, table_list) ||
|
|
|
|
open_and_lock_tables(thd, table_list))
|
|
|
|
goto error;
|
2002-06-12 23:13:12 +02:00
|
|
|
|
2005-06-08 17:31:34 +02:00
|
|
|
if (!table_list->table)
|
2004-04-10 00:14:32 +02:00
|
|
|
{
|
2005-06-08 17:31:34 +02:00
|
|
|
my_error(ER_VIEW_DELETE_MERGE_VIEW, MYF(0),
|
|
|
|
table_list->view_db.str, table_list->view_name.str);
|
|
|
|
goto error;
|
2004-04-10 00:14:32 +02:00
|
|
|
}
|
2005-06-08 17:31:34 +02:00
|
|
|
|
|
|
|
DBUG_RETURN(mysql_prepare_delete(thd, table_list, &lex->select_lex.where));
|
|
|
|
error:
|
2004-10-20 03:04:37 +02:00
|
|
|
DBUG_RETURN(TRUE);
|
2002-06-12 23:13:12 +02:00
|
|
|
}
|
|
|
|
|
2004-04-10 00:14:32 +02:00
|
|
|
|
2002-06-12 23:13:12 +02:00
|
|
|
/*
|
2004-04-10 00:14:32 +02:00
|
|
|
Validate SELECT statement.
|
|
|
|
|
2004-03-02 20:39:50 +01:00
|
|
|
SYNOPSIS
|
2004-04-10 00:14:32 +02:00
|
|
|
mysql_test_select()
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
stmt prepared statement
|
|
|
|
tables list of tables used in the query
|
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
In case of success, if this query is not EXPLAIN, send column list info
|
|
|
|
back to the client.
|
2004-04-10 00:14:32 +02:00
|
|
|
|
2004-03-02 20:39:50 +01:00
|
|
|
RETURN VALUE
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
0 success
|
|
|
|
1 error, error message is set in THD
|
|
|
|
2 success, and statement metadata has been sent
|
2002-06-12 23:13:12 +02:00
|
|
|
*/
|
2003-12-20 00:16:10 +01:00
|
|
|
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
static int mysql_test_select(Prepared_statement *stmt,
|
|
|
|
TABLE_LIST *tables, bool text_protocol)
|
2002-06-12 23:13:12 +02:00
|
|
|
{
|
2002-10-02 12:33:08 +02:00
|
|
|
THD *thd= stmt->thd;
|
2003-12-20 00:16:10 +01:00
|
|
|
LEX *lex= stmt->lex;
|
2004-04-07 23:16:17 +02:00
|
|
|
SELECT_LEX_UNIT *unit= &lex->unit;
|
2004-04-10 00:14:32 +02:00
|
|
|
DBUG_ENTER("mysql_test_select");
|
2002-06-12 23:13:12 +02:00
|
|
|
|
2005-07-01 06:05:42 +02:00
|
|
|
lex->select_lex.context.resolve_in_select_list= TRUE;
|
|
|
|
|
2003-09-26 12:33:13 +02:00
|
|
|
#ifndef NO_EMBEDDED_ACCESS_CHECKS
|
2003-02-25 02:22:02 +01:00
|
|
|
ulong privilege= lex->exchange ? SELECT_ACL | FILE_ACL : SELECT_ACL;
|
|
|
|
if (tables)
|
|
|
|
{
|
2003-09-26 12:33:13 +02:00
|
|
|
if (check_table_access(thd, privilege, tables,0))
|
2005-06-08 17:31:34 +02:00
|
|
|
goto error;
|
2003-02-25 02:22:02 +01:00
|
|
|
}
|
2005-09-13 13:07:38 +02:00
|
|
|
else if (check_access(thd, privilege, any_db,0,0,0,0))
|
2005-06-08 17:31:34 +02:00
|
|
|
goto error;
|
2003-09-26 12:33:13 +02:00
|
|
|
#endif
|
2004-02-20 14:37:45 +01:00
|
|
|
|
2004-11-08 00:13:54 +01:00
|
|
|
if (!lex->result && !(lex->result= new (stmt->mem_root) select_send))
|
2005-06-08 17:31:34 +02:00
|
|
|
{
|
|
|
|
my_error(ER_OUTOFMEMORY, MYF(0), sizeof(select_send));
|
|
|
|
goto error;
|
|
|
|
}
|
2004-10-21 16:33:53 +02:00
|
|
|
|
2004-11-13 18:35:51 +01:00
|
|
|
if (open_and_lock_tables(thd, tables))
|
2005-06-08 17:31:34 +02:00
|
|
|
goto error;
|
2002-06-12 23:13:12 +02:00
|
|
|
|
2004-06-25 10:37:43 +02:00
|
|
|
thd->used_tables= 0; // Updated by setup_fields
|
|
|
|
|
2005-01-03 20:04:33 +01:00
|
|
|
/*
|
|
|
|
JOIN::prepare calls
|
|
|
|
It is not SELECT COMMAND for sure, so setup_tables will be called as
|
|
|
|
usual, and we pass 0 as setup_tables_done_option
|
|
|
|
*/
|
2005-09-22 00:11:21 +02:00
|
|
|
if (unit->prepare(thd, 0, 0))
|
2005-06-08 17:31:34 +02:00
|
|
|
goto error;
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
if (!lex->describe && !text_protocol)
|
2003-03-04 23:22:30 +01:00
|
|
|
{
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
/* Make copy of item list, as change_columns may change it */
|
|
|
|
List<Item> fields(lex->select_lex.item_list);
|
2004-10-26 18:30:01 +02:00
|
|
|
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
/* Change columns if a procedure like analyse() */
|
|
|
|
if (unit->last_procedure && unit->last_procedure->change_columns(fields))
|
|
|
|
goto error;
|
2004-10-26 18:30:01 +02:00
|
|
|
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
/*
|
|
|
|
We can use lex->result as it should've been prepared in
|
|
|
|
unit->prepare call above.
|
|
|
|
*/
|
|
|
|
if (send_prep_stmt(stmt, lex->result->field_count(fields)) ||
|
|
|
|
lex->result->send_fields(fields, Protocol::SEND_EOF) ||
|
|
|
|
thd->protocol->flush())
|
|
|
|
goto error;
|
|
|
|
DBUG_RETURN(2);
|
2003-03-04 23:22:30 +01:00
|
|
|
}
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
DBUG_RETURN(0);
|
2005-06-08 17:31:34 +02:00
|
|
|
error:
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
DBUG_RETURN(1);
|
2002-06-12 23:13:12 +02:00
|
|
|
}
|
|
|
|
|
2002-10-02 12:33:08 +02:00
|
|
|
|
2004-04-07 23:16:17 +02:00
|
|
|
/*
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
Validate and prepare for execution DO statement expressions.
|
2004-04-07 23:16:17 +02:00
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
mysql_test_do_fields()
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
stmt prepared statement
|
|
|
|
tables list of tables used in this query
|
|
|
|
values list of expressions
|
2004-04-07 23:16:17 +02:00
|
|
|
|
|
|
|
RETURN VALUE
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
FALSE success
|
|
|
|
TRUE error, error message is set in THD
|
2004-04-07 23:16:17 +02:00
|
|
|
*/
|
|
|
|
|
2004-10-20 03:04:37 +02:00
|
|
|
static bool mysql_test_do_fields(Prepared_statement *stmt,
|
2005-06-08 17:57:26 +02:00
|
|
|
TABLE_LIST *tables,
|
|
|
|
List<Item> *values)
|
2004-04-07 23:16:17 +02:00
|
|
|
{
|
|
|
|
THD *thd= stmt->thd;
|
2005-06-08 17:31:34 +02:00
|
|
|
|
|
|
|
DBUG_ENTER("mysql_test_do_fields");
|
2004-10-20 03:04:37 +02:00
|
|
|
if (tables && check_table_access(thd, SELECT_ACL, tables, 0))
|
|
|
|
DBUG_RETURN(TRUE);
|
2004-08-21 00:02:46 +02:00
|
|
|
|
2005-03-10 14:05:48 +01:00
|
|
|
if (open_and_lock_tables(thd, tables))
|
2004-10-20 03:04:37 +02:00
|
|
|
DBUG_RETURN(TRUE);
|
2005-07-01 06:05:42 +02:00
|
|
|
DBUG_RETURN(setup_fields(thd, 0, *values, 0, 0, 0));
|
2004-04-07 23:16:17 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
Validate and prepare for execution SET statement expressions
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
mysql_test_set_fields()
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
stmt prepared statement
|
|
|
|
tables list of tables used in this query
|
|
|
|
values list of expressions
|
2004-04-07 23:16:17 +02:00
|
|
|
|
|
|
|
RETURN VALUE
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
FALSE success
|
|
|
|
TRUE error, error message is set in THD
|
2004-04-07 23:16:17 +02:00
|
|
|
*/
|
2005-06-08 17:31:34 +02:00
|
|
|
|
2004-10-20 03:04:37 +02:00
|
|
|
static bool mysql_test_set_fields(Prepared_statement *stmt,
|
|
|
|
TABLE_LIST *tables,
|
|
|
|
List<set_var_base> *var_list)
|
2004-04-07 23:16:17 +02:00
|
|
|
{
|
|
|
|
DBUG_ENTER("mysql_test_set_fields");
|
|
|
|
List_iterator_fast<set_var_base> it(*var_list);
|
|
|
|
THD *thd= stmt->thd;
|
|
|
|
set_var_base *var;
|
2004-08-21 00:02:46 +02:00
|
|
|
|
2005-06-08 17:31:34 +02:00
|
|
|
if (tables && check_table_access(thd, SELECT_ACL, tables, 0) ||
|
|
|
|
open_and_lock_tables(thd, tables))
|
2004-04-07 23:16:17 +02:00
|
|
|
goto error;
|
2005-06-08 17:31:34 +02:00
|
|
|
|
2004-04-07 23:16:17 +02:00
|
|
|
while ((var= it++))
|
|
|
|
{
|
|
|
|
if (var->light_check(thd))
|
|
|
|
goto error;
|
|
|
|
}
|
2005-06-08 17:31:34 +02:00
|
|
|
DBUG_RETURN(FALSE);
|
2004-04-07 23:16:17 +02:00
|
|
|
error:
|
2005-06-08 17:31:34 +02:00
|
|
|
DBUG_RETURN(TRUE);
|
2004-04-07 23:16:17 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
Check internal SELECT of the prepared command
|
|
|
|
|
|
|
|
SYNOPSIS
|
2005-03-10 14:05:48 +01:00
|
|
|
select_like_stmt_test()
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
stmt prepared statement
|
|
|
|
specific_prepare function of command specific prepare
|
|
|
|
setup_tables_done_option options to be passed to LEX::unit.prepare()
|
2005-03-10 14:05:48 +01:00
|
|
|
|
|
|
|
NOTE
|
|
|
|
This function won't directly open tables used in select. They should
|
|
|
|
be opened either by calling function (and in this case you probably
|
|
|
|
should use select_like_stmt_test_with_open_n_lock()) or by
|
|
|
|
"specific_prepare" call (like this happens in case of multi-update).
|
2004-04-07 23:16:17 +02:00
|
|
|
|
2004-04-10 00:14:32 +02:00
|
|
|
RETURN VALUE
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
FALSE success
|
|
|
|
TRUE error, error message is set in THD
|
2004-04-07 23:16:17 +02:00
|
|
|
*/
|
2005-03-10 14:05:48 +01:00
|
|
|
|
|
|
|
static bool select_like_stmt_test(Prepared_statement *stmt,
|
|
|
|
bool (*specific_prepare)(THD *thd),
|
|
|
|
ulong setup_tables_done_option)
|
2004-04-07 23:16:17 +02:00
|
|
|
{
|
2005-03-10 14:05:48 +01:00
|
|
|
DBUG_ENTER("select_like_stmt_test");
|
2004-04-07 23:16:17 +02:00
|
|
|
THD *thd= stmt->thd;
|
|
|
|
LEX *lex= stmt->lex;
|
|
|
|
|
2005-07-01 06:05:42 +02:00
|
|
|
lex->select_lex.context.resolve_in_select_list= TRUE;
|
|
|
|
|
2005-06-08 17:31:34 +02:00
|
|
|
if (specific_prepare && (*specific_prepare)(thd))
|
|
|
|
DBUG_RETURN(TRUE);
|
2004-07-16 00:15:55 +02:00
|
|
|
|
2004-04-07 23:16:17 +02:00
|
|
|
thd->used_tables= 0; // Updated by setup_fields
|
|
|
|
|
2005-06-08 17:31:34 +02:00
|
|
|
/* Calls JOIN::prepare */
|
2005-09-22 00:11:21 +02:00
|
|
|
DBUG_RETURN(lex->unit.prepare(thd, 0, setup_tables_done_option));
|
2004-04-07 23:16:17 +02:00
|
|
|
}
|
|
|
|
|
2005-03-10 14:05:48 +01:00
|
|
|
/*
|
|
|
|
Check internal SELECT of the prepared command (with opening and
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
locking of used tables).
|
2005-03-10 14:05:48 +01:00
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
select_like_stmt_test_with_open_n_lock()
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
stmt prepared statement
|
|
|
|
tables list of tables to be opened and locked
|
|
|
|
before calling specific_prepare function
|
|
|
|
specific_prepare function of command specific prepare
|
|
|
|
setup_tables_done_option options to be passed to LEX::unit.prepare()
|
2005-03-10 14:05:48 +01:00
|
|
|
|
|
|
|
RETURN VALUE
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
FALSE success
|
|
|
|
TRUE error
|
2005-03-10 14:05:48 +01:00
|
|
|
*/
|
|
|
|
|
|
|
|
static bool
|
|
|
|
select_like_stmt_test_with_open_n_lock(Prepared_statement *stmt,
|
|
|
|
TABLE_LIST *tables,
|
|
|
|
bool (*specific_prepare)(THD *thd),
|
|
|
|
ulong setup_tables_done_option)
|
|
|
|
{
|
|
|
|
DBUG_ENTER("select_like_stmt_test_with_open_n_lock");
|
|
|
|
|
|
|
|
/*
|
|
|
|
We should not call LEX::unit.cleanup() after this open_and_lock_tables()
|
|
|
|
call because we don't allow prepared EXPLAIN yet so derived tables will
|
|
|
|
clean up after themself.
|
|
|
|
*/
|
|
|
|
if (open_and_lock_tables(stmt->thd, tables))
|
|
|
|
DBUG_RETURN(TRUE);
|
|
|
|
|
|
|
|
DBUG_RETURN(select_like_stmt_test(stmt, specific_prepare,
|
|
|
|
setup_tables_done_option));
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2004-04-07 23:16:17 +02:00
|
|
|
/*
|
2004-05-25 00:03:49 +02:00
|
|
|
Validate and prepare for execution CREATE TABLE statement
|
2004-04-07 23:16:17 +02:00
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
mysql_test_create_table()
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
stmt prepared statement
|
|
|
|
tables list of tables used in this query
|
2004-04-07 23:16:17 +02:00
|
|
|
|
|
|
|
RETURN VALUE
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
FALSE success
|
|
|
|
TRUE error, error message is set in THD
|
2004-04-07 23:16:17 +02:00
|
|
|
*/
|
2004-09-09 06:26:28 +02:00
|
|
|
|
2005-06-08 17:31:34 +02:00
|
|
|
static bool mysql_test_create_table(Prepared_statement *stmt)
|
2004-04-07 23:16:17 +02:00
|
|
|
{
|
|
|
|
DBUG_ENTER("mysql_test_create_table");
|
|
|
|
THD *thd= stmt->thd;
|
|
|
|
LEX *lex= stmt->lex;
|
2004-06-13 21:39:09 +02:00
|
|
|
SELECT_LEX *select_lex= &lex->select_lex;
|
2005-06-08 17:31:34 +02:00
|
|
|
bool res= FALSE;
|
2004-04-07 23:16:17 +02:00
|
|
|
/* Skip first table, which is the table we are creating */
|
2004-07-16 00:15:55 +02:00
|
|
|
bool link_to_local;
|
|
|
|
TABLE_LIST *create_table= lex->unlink_first_table(&link_to_local);
|
|
|
|
TABLE_LIST *tables= lex->query_tables;
|
2004-04-07 23:16:17 +02:00
|
|
|
|
2005-06-08 17:31:34 +02:00
|
|
|
if (create_table_precheck(thd, tables, create_table))
|
|
|
|
DBUG_RETURN(TRUE);
|
|
|
|
|
|
|
|
if (select_lex->item_list.elements)
|
2004-06-13 21:39:09 +02:00
|
|
|
{
|
2005-07-01 06:05:42 +02:00
|
|
|
select_lex->context.resolve_in_select_list= TRUE;
|
2005-03-10 14:05:48 +01:00
|
|
|
res= select_like_stmt_test_with_open_n_lock(stmt, tables, 0, 0);
|
2004-06-13 21:39:09 +02:00
|
|
|
}
|
2004-04-07 23:16:17 +02:00
|
|
|
|
2004-04-10 00:14:32 +02:00
|
|
|
/* put tables back for PS rexecuting */
|
2004-07-16 00:15:55 +02:00
|
|
|
lex->link_first_table_back(create_table, link_to_local);
|
2004-04-07 23:16:17 +02:00
|
|
|
DBUG_RETURN(res);
|
|
|
|
}
|
|
|
|
|
2004-04-10 00:14:32 +02:00
|
|
|
|
2004-04-07 23:16:17 +02:00
|
|
|
/*
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
Validate and prepare for execution a multi update statement.
|
2004-04-07 23:16:17 +02:00
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
mysql_test_multiupdate()
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
stmt prepared statement
|
|
|
|
tables list of tables used in this query
|
|
|
|
converted converted to multi-update from usual update
|
2004-04-07 23:16:17 +02:00
|
|
|
|
|
|
|
RETURN VALUE
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
FALSE success
|
|
|
|
TRUE error, error message is set in THD
|
2004-04-07 23:16:17 +02:00
|
|
|
*/
|
2004-10-20 03:04:37 +02:00
|
|
|
|
|
|
|
static bool mysql_test_multiupdate(Prepared_statement *stmt,
|
2005-06-08 17:57:26 +02:00
|
|
|
TABLE_LIST *tables,
|
2004-09-15 22:42:56 +02:00
|
|
|
bool converted)
|
2004-04-07 23:16:17 +02:00
|
|
|
{
|
2004-11-25 08:28:32 +01:00
|
|
|
/* if we switched from normal update, rights are checked */
|
2004-11-21 19:08:12 +01:00
|
|
|
if (!converted && multi_update_precheck(stmt->thd, tables))
|
2004-10-20 03:04:37 +02:00
|
|
|
return TRUE;
|
2005-03-10 14:05:48 +01:00
|
|
|
|
|
|
|
return select_like_stmt_test(stmt, &mysql_multi_update_prepare,
|
|
|
|
OPTION_SETUP_TABLES_DONE);
|
2004-04-07 23:16:17 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
Validate and prepare for execution a multi delete statement.
|
2004-04-07 23:16:17 +02:00
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
mysql_test_multidelete()
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
stmt prepared statement
|
|
|
|
tables list of tables used in this query
|
2004-04-07 23:16:17 +02:00
|
|
|
|
|
|
|
RETURN VALUE
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
FALSE success
|
|
|
|
TRUE error, error message in THD is set.
|
2004-04-07 23:16:17 +02:00
|
|
|
*/
|
2005-06-08 17:31:34 +02:00
|
|
|
|
|
|
|
static bool mysql_test_multidelete(Prepared_statement *stmt,
|
2005-06-08 17:57:26 +02:00
|
|
|
TABLE_LIST *tables)
|
2004-04-07 23:16:17 +02:00
|
|
|
{
|
|
|
|
stmt->thd->lex->current_select= &stmt->thd->lex->select_lex;
|
|
|
|
if (add_item_to_list(stmt->thd, new Item_null()))
|
2005-06-08 17:31:34 +02:00
|
|
|
{
|
|
|
|
my_error(ER_OUTOFMEMORY, MYF(0), 0);
|
|
|
|
goto error;
|
|
|
|
}
|
2004-04-07 23:16:17 +02:00
|
|
|
|
2005-06-08 23:13:20 +02:00
|
|
|
if (multi_delete_precheck(stmt->thd, tables) ||
|
2005-06-08 17:31:34 +02:00
|
|
|
select_like_stmt_test_with_open_n_lock(stmt, tables,
|
|
|
|
&mysql_multi_delete_prepare,
|
|
|
|
OPTION_SETUP_TABLES_DONE))
|
|
|
|
goto error;
|
2004-09-15 22:42:56 +02:00
|
|
|
if (!tables->table)
|
|
|
|
{
|
|
|
|
my_error(ER_VIEW_DELETE_MERGE_VIEW, MYF(0),
|
2005-06-08 17:57:26 +02:00
|
|
|
tables->view_db.str, tables->view_name.str);
|
2005-06-08 17:31:34 +02:00
|
|
|
goto error;
|
2004-09-15 22:42:56 +02:00
|
|
|
}
|
2005-06-08 17:31:34 +02:00
|
|
|
return FALSE;
|
|
|
|
error:
|
|
|
|
return TRUE;
|
2004-04-07 23:16:17 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2005-01-04 17:04:16 +01:00
|
|
|
/*
|
|
|
|
Wrapper for mysql_insert_select_prepare, to make change of local tables
|
|
|
|
after open_and_lock_tables() call.
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
mysql_insert_select_prepare_tester()
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
thd thread handle
|
2005-01-04 17:04:16 +01:00
|
|
|
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
NOTE
|
|
|
|
We need to remove the first local table after open_and_lock_tables,
|
|
|
|
because mysql_handle_derived uses local tables lists.
|
2005-01-04 17:04:16 +01:00
|
|
|
*/
|
|
|
|
|
|
|
|
static bool mysql_insert_select_prepare_tester(THD *thd)
|
|
|
|
{
|
2005-07-01 06:05:42 +02:00
|
|
|
TABLE_LIST *first;
|
|
|
|
bool res;
|
2005-01-04 17:04:16 +01:00
|
|
|
SELECT_LEX *first_select= &thd->lex->select_lex;
|
|
|
|
/* Skip first table, which is the table we are inserting in */
|
2005-07-01 06:05:42 +02:00
|
|
|
first_select->table_list.first= (byte*)(first=
|
|
|
|
((TABLE_LIST*)first_select->
|
|
|
|
table_list.first)->next_local);
|
|
|
|
res= mysql_insert_select_prepare(thd);
|
2005-01-04 17:04:16 +01:00
|
|
|
/*
|
|
|
|
insert/replace from SELECT give its SELECT_LEX for SELECT,
|
|
|
|
and item_list belong to SELECT
|
|
|
|
*/
|
2005-07-01 06:05:42 +02:00
|
|
|
thd->lex->select_lex.context.resolve_in_select_list= TRUE;
|
|
|
|
thd->lex->select_lex.context.table_list= first;
|
|
|
|
return res;
|
2005-01-04 17:04:16 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2004-04-07 23:16:17 +02:00
|
|
|
/*
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
Validate and prepare for execution INSERT ... SELECT statement.
|
2004-04-07 23:16:17 +02:00
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
mysql_test_insert_select()
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
stmt prepared statement
|
|
|
|
tables list of tables used in this query
|
2004-04-07 23:16:17 +02:00
|
|
|
|
|
|
|
RETURN VALUE
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
FALSE success
|
|
|
|
TRUE error, error message is set in THD
|
2004-04-07 23:16:17 +02:00
|
|
|
*/
|
2004-12-30 23:44:00 +01:00
|
|
|
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
static bool mysql_test_insert_select(Prepared_statement *stmt,
|
|
|
|
TABLE_LIST *tables)
|
2004-04-07 23:16:17 +02:00
|
|
|
{
|
|
|
|
int res;
|
|
|
|
LEX *lex= stmt->lex;
|
2004-12-30 23:44:00 +01:00
|
|
|
TABLE_LIST *first_local_table;
|
|
|
|
|
2005-01-03 12:56:23 +01:00
|
|
|
if (tables->table)
|
|
|
|
{
|
|
|
|
// don't allocate insert_values
|
|
|
|
tables->table->insert_values=(byte *)1;
|
|
|
|
}
|
2004-12-30 23:44:00 +01:00
|
|
|
|
2005-06-08 17:31:34 +02:00
|
|
|
if (insert_precheck(stmt->thd, tables))
|
|
|
|
return 1;
|
2005-01-04 17:04:16 +01:00
|
|
|
|
|
|
|
/* store it, because mysql_insert_select_prepare_tester change it */
|
|
|
|
first_local_table= (TABLE_LIST *)lex->select_lex.table_list.first;
|
|
|
|
DBUG_ASSERT(first_local_table != 0);
|
|
|
|
|
2005-07-01 06:05:42 +02:00
|
|
|
res=
|
|
|
|
select_like_stmt_test_with_open_n_lock(stmt, tables,
|
|
|
|
&mysql_insert_select_prepare_tester,
|
|
|
|
OPTION_SETUP_TABLES_DONE);
|
2005-01-04 17:04:16 +01:00
|
|
|
/* revert changes made by mysql_insert_select_prepare_tester */
|
2004-05-05 15:54:11 +02:00
|
|
|
lex->select_lex.table_list.first= (byte*) first_local_table;
|
2004-04-07 23:16:17 +02:00
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2002-06-12 23:13:12 +02:00
|
|
|
/*
|
2004-11-11 21:30:39 +01:00
|
|
|
Perform semantic analysis of the parsed tree and send a response packet
|
|
|
|
to the client.
|
|
|
|
|
2004-03-02 20:39:50 +01:00
|
|
|
SYNOPSIS
|
2004-11-11 21:30:39 +01:00
|
|
|
check_prepared_statement()
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
stmt prepared statement
|
2004-11-11 21:30:39 +01:00
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
This function
|
|
|
|
- opens all tables and checks access rights
|
|
|
|
- validates semantics of statement columns and SQL functions
|
|
|
|
by calling fix_fields.
|
|
|
|
|
2004-03-02 20:39:50 +01:00
|
|
|
RETURN VALUE
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
FALSE success, statement metadata is sent to client
|
|
|
|
TRUE error, error message is set in THD (but not sent)
|
2002-06-12 23:13:12 +02:00
|
|
|
*/
|
2004-11-11 21:30:39 +01:00
|
|
|
|
2005-06-08 17:31:34 +02:00
|
|
|
static bool check_prepared_statement(Prepared_statement *stmt,
|
|
|
|
bool text_protocol)
|
2004-11-11 21:30:39 +01:00
|
|
|
{
|
2002-10-02 12:33:08 +02:00
|
|
|
THD *thd= stmt->thd;
|
2003-12-20 00:16:10 +01:00
|
|
|
LEX *lex= stmt->lex;
|
2004-03-02 20:39:50 +01:00
|
|
|
SELECT_LEX *select_lex= &lex->select_lex;
|
2004-07-16 00:15:55 +02:00
|
|
|
TABLE_LIST *tables;
|
2003-12-20 00:16:10 +01:00
|
|
|
enum enum_sql_command sql_command= lex->sql_command;
|
2004-04-10 00:14:32 +02:00
|
|
|
int res= 0;
|
2004-11-11 21:30:39 +01:00
|
|
|
DBUG_ENTER("check_prepared_statement");
|
2002-10-02 12:33:08 +02:00
|
|
|
DBUG_PRINT("enter",("command: %d, param_count: %ld",
|
2004-03-02 20:39:50 +01:00
|
|
|
sql_command, stmt->param_count));
|
2004-04-07 23:16:17 +02:00
|
|
|
|
2004-07-16 00:15:55 +02:00
|
|
|
lex->first_lists_tables_same();
|
|
|
|
tables= lex->query_tables;
|
2004-04-07 23:16:17 +02:00
|
|
|
|
2005-07-01 06:05:42 +02:00
|
|
|
/* set context for commands which do not use setup_tables */
|
|
|
|
lex->select_lex.context.resolve_in_table_list_only(select_lex->
|
|
|
|
get_table_list());
|
|
|
|
|
2002-10-02 12:33:08 +02:00
|
|
|
switch (sql_command) {
|
2004-04-07 23:16:17 +02:00
|
|
|
case SQLCOM_REPLACE:
|
2002-06-12 23:13:12 +02:00
|
|
|
case SQLCOM_INSERT:
|
2004-04-10 00:14:32 +02:00
|
|
|
res= mysql_test_insert(stmt, tables, lex->field_list,
|
2005-06-08 17:57:26 +02:00
|
|
|
lex->many_values,
|
|
|
|
select_lex->item_list, lex->value_list,
|
|
|
|
lex->duplicates);
|
2002-06-12 23:13:12 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case SQLCOM_UPDATE:
|
2004-04-10 00:14:32 +02:00
|
|
|
res= mysql_test_update(stmt, tables);
|
2005-06-08 17:31:34 +02:00
|
|
|
/* mysql_test_update returns 2 if we need to switch to multi-update */
|
2004-09-15 22:42:56 +02:00
|
|
|
if (res != 2)
|
|
|
|
break;
|
|
|
|
|
|
|
|
case SQLCOM_UPDATE_MULTI:
|
|
|
|
res= mysql_test_multiupdate(stmt, tables, res == 2);
|
2004-04-10 00:14:32 +02:00
|
|
|
break;
|
|
|
|
|
2002-06-12 23:13:12 +02:00
|
|
|
case SQLCOM_DELETE:
|
2004-04-10 00:14:32 +02:00
|
|
|
res= mysql_test_delete(stmt, tables);
|
2002-06-12 23:13:12 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case SQLCOM_SELECT:
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
res= mysql_test_select(stmt, tables, text_protocol);
|
|
|
|
if (res == 2)
|
|
|
|
{
|
|
|
|
/* Statement and field info has already been sent */
|
|
|
|
DBUG_RETURN(FALSE);
|
|
|
|
}
|
|
|
|
break;
|
2004-04-07 23:16:17 +02:00
|
|
|
case SQLCOM_CREATE_TABLE:
|
2004-07-16 00:15:55 +02:00
|
|
|
res= mysql_test_create_table(stmt);
|
2004-04-07 23:16:17 +02:00
|
|
|
break;
|
2005-06-08 17:57:26 +02:00
|
|
|
|
2004-04-07 23:16:17 +02:00
|
|
|
case SQLCOM_DO:
|
2004-04-10 00:14:32 +02:00
|
|
|
res= mysql_test_do_fields(stmt, tables, lex->insert_list);
|
|
|
|
break;
|
2004-04-07 23:16:17 +02:00
|
|
|
|
|
|
|
case SQLCOM_SET_OPTION:
|
2004-04-10 00:14:32 +02:00
|
|
|
res= mysql_test_set_fields(stmt, tables, &lex->var_list);
|
2004-04-07 23:16:17 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case SQLCOM_DELETE_MULTI:
|
2004-04-10 00:14:32 +02:00
|
|
|
res= mysql_test_multidelete(stmt, tables);
|
2004-04-07 23:16:17 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case SQLCOM_INSERT_SELECT:
|
2004-10-30 15:17:52 +02:00
|
|
|
case SQLCOM_REPLACE_SELECT:
|
2004-04-10 00:14:32 +02:00
|
|
|
res= mysql_test_insert_select(stmt, tables);
|
2004-04-07 23:16:17 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case SQLCOM_SHOW_DATABASES:
|
|
|
|
case SQLCOM_SHOW_PROCESSLIST:
|
|
|
|
case SQLCOM_SHOW_STORAGE_ENGINES:
|
|
|
|
case SQLCOM_SHOW_PRIVILEGES:
|
|
|
|
case SQLCOM_SHOW_COLUMN_TYPES:
|
|
|
|
case SQLCOM_SHOW_STATUS:
|
|
|
|
case SQLCOM_SHOW_VARIABLES:
|
|
|
|
case SQLCOM_SHOW_LOGS:
|
|
|
|
case SQLCOM_SHOW_TABLES:
|
|
|
|
case SQLCOM_SHOW_OPEN_TABLES:
|
|
|
|
case SQLCOM_SHOW_CHARSETS:
|
|
|
|
case SQLCOM_SHOW_COLLATIONS:
|
|
|
|
case SQLCOM_SHOW_FIELDS:
|
|
|
|
case SQLCOM_SHOW_KEYS:
|
|
|
|
case SQLCOM_SHOW_CREATE_DB:
|
|
|
|
case SQLCOM_SHOW_GRANTS:
|
|
|
|
case SQLCOM_DROP_TABLE:
|
|
|
|
case SQLCOM_RENAME_TABLE:
|
2004-08-03 12:32:21 +02:00
|
|
|
case SQLCOM_ALTER_TABLE:
|
|
|
|
case SQLCOM_COMMIT:
|
|
|
|
case SQLCOM_CREATE_INDEX:
|
|
|
|
case SQLCOM_DROP_INDEX:
|
|
|
|
case SQLCOM_ROLLBACK:
|
|
|
|
case SQLCOM_TRUNCATE:
|
2005-04-13 21:36:15 +02:00
|
|
|
case SQLCOM_CALL:
|
2005-10-24 22:54:04 +02:00
|
|
|
case SQLCOM_CREATE_VIEW:
|
|
|
|
case SQLCOM_DROP_VIEW:
|
2006-04-25 02:27:23 +02:00
|
|
|
case SQLCOM_REPAIR:
|
|
|
|
case SQLCOM_ANALYZE:
|
|
|
|
case SQLCOM_OPTIMIZE:
|
2004-04-07 23:16:17 +02:00
|
|
|
break;
|
|
|
|
|
2002-06-12 23:13:12 +02:00
|
|
|
default:
|
2005-06-08 17:31:34 +02:00
|
|
|
/* All other statements are not supported yet. */
|
2004-11-12 13:34:00 +01:00
|
|
|
my_message(ER_UNSUPPORTED_PS, ER(ER_UNSUPPORTED_PS), MYF(0));
|
2004-04-07 23:16:17 +02:00
|
|
|
goto error;
|
2002-06-12 23:13:12 +02:00
|
|
|
}
|
2004-04-10 00:14:32 +02:00
|
|
|
if (res == 0)
|
2005-06-08 17:31:34 +02:00
|
|
|
DBUG_RETURN(text_protocol? FALSE : (send_prep_stmt(stmt, 0) ||
|
|
|
|
thd->protocol->flush()));
|
2004-03-02 20:39:50 +01:00
|
|
|
error:
|
2005-06-08 17:31:34 +02:00
|
|
|
DBUG_RETURN(TRUE);
|
2002-06-12 23:13:12 +02:00
|
|
|
}
|
|
|
|
|
2002-11-22 19:04:42 +01:00
|
|
|
/*
|
2004-05-25 00:03:49 +02:00
|
|
|
Initialize array of parameters in statement from LEX.
|
|
|
|
(We need to have quick access to items by number in mysql_stmt_get_longdata).
|
2004-03-02 20:39:50 +01:00
|
|
|
This is to avoid using malloc/realloc in the parser.
|
2002-11-22 19:04:42 +01:00
|
|
|
*/
|
2003-01-03 12:52:53 +01:00
|
|
|
|
2004-03-02 20:39:50 +01:00
|
|
|
static bool init_param_array(Prepared_statement *stmt)
|
2002-11-22 19:04:42 +01:00
|
|
|
{
|
2004-03-02 20:39:50 +01:00
|
|
|
LEX *lex= stmt->lex;
|
|
|
|
if ((stmt->param_count= lex->param_list.elements))
|
|
|
|
{
|
2004-09-08 21:07:11 +02:00
|
|
|
if (stmt->param_count > (uint) UINT_MAX16)
|
|
|
|
{
|
|
|
|
/* Error code to be defined in 5.0 */
|
2004-11-13 18:35:51 +01:00
|
|
|
my_message(ER_PS_MANY_PARAM, ER(ER_PS_MANY_PARAM), MYF(0));
|
|
|
|
return TRUE;
|
2004-09-08 21:07:11 +02:00
|
|
|
}
|
2004-03-02 20:39:50 +01:00
|
|
|
Item_param **to;
|
|
|
|
List_iterator<Item_param> param_iterator(lex->param_list);
|
|
|
|
/* Use thd->mem_root as it points at statement mem_root */
|
|
|
|
stmt->param_array= (Item_param **)
|
2004-11-08 00:13:54 +01:00
|
|
|
alloc_root(stmt->thd->mem_root,
|
2004-03-02 20:39:50 +01:00
|
|
|
sizeof(Item_param*) * stmt->param_count);
|
|
|
|
if (!stmt->param_array)
|
2004-11-13 18:35:51 +01:00
|
|
|
return TRUE;
|
2004-03-02 20:39:50 +01:00
|
|
|
for (to= stmt->param_array;
|
|
|
|
to < stmt->param_array + stmt->param_count;
|
|
|
|
++to)
|
|
|
|
{
|
|
|
|
*to= param_iterator++;
|
|
|
|
}
|
|
|
|
}
|
2004-11-13 18:35:51 +01:00
|
|
|
return FALSE;
|
2002-11-22 19:04:42 +01:00
|
|
|
}
|
2002-10-02 12:33:08 +02:00
|
|
|
|
2005-06-09 16:17:45 +02:00
|
|
|
|
2002-06-12 23:13:12 +02:00
|
|
|
/*
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
COM_STMT_PREPARE handler.
|
2005-06-08 17:57:26 +02:00
|
|
|
|
2004-04-12 23:58:48 +02:00
|
|
|
SYNOPSIS
|
|
|
|
mysql_stmt_prepare()
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
packet query to be prepared
|
|
|
|
packet_length query string length, including ignored
|
|
|
|
trailing NULL or quote char.
|
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
Given a query string with parameter markers, create a prepared
|
|
|
|
statement from it and send PS info back to the client.
|
2004-10-20 03:04:37 +02:00
|
|
|
|
2004-05-21 02:27:50 +02:00
|
|
|
NOTES
|
2005-06-08 17:57:26 +02:00
|
|
|
This function parses the query and sends the total number of parameters
|
|
|
|
and resultset metadata information back to client (if any), without
|
|
|
|
executing the query i.e. without any log/disk writes. This allows the
|
|
|
|
queries to be re-executed without re-parsing during execute.
|
2004-05-21 02:27:50 +02:00
|
|
|
|
|
|
|
If parameter markers are found in the query, then store the information
|
2005-06-08 17:57:26 +02:00
|
|
|
using Item_param along with maintaining a list in lex->param_array, so
|
|
|
|
that a fast and direct retrieval can be made without going through all
|
2004-05-21 02:27:50 +02:00
|
|
|
field items.
|
2005-06-08 17:57:26 +02:00
|
|
|
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
RETURN VALUE
|
|
|
|
none: in case of success a new statement id and metadata is sent
|
|
|
|
to the client, otherwise an error message is set in THD.
|
2002-06-12 23:13:12 +02:00
|
|
|
*/
|
|
|
|
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
void mysql_stmt_prepare(THD *thd, const char *packet, uint packet_length)
|
2002-06-12 23:13:12 +02:00
|
|
|
{
|
2005-11-17 17:40:48 +01:00
|
|
|
Prepared_statement *stmt;
|
2005-10-06 16:54:43 +02:00
|
|
|
bool error;
|
2002-10-02 12:33:08 +02:00
|
|
|
DBUG_ENTER("mysql_stmt_prepare");
|
2002-06-12 23:13:12 +02:00
|
|
|
|
2004-04-07 12:25:24 +02:00
|
|
|
DBUG_PRINT("prep_query", ("%s", packet));
|
2004-04-03 10:13:51 +02:00
|
|
|
|
2005-11-17 17:40:48 +01:00
|
|
|
/* First of all clear possible warnings from the previous command */
|
|
|
|
mysql_reset_thd_for_next_command(thd);
|
|
|
|
|
|
|
|
if (! (stmt= new Prepared_statement(thd, &thd->protocol_prep)))
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
DBUG_VOID_RETURN; /* out of memory: error is set in Sql_alloc */
|
2002-10-02 12:33:08 +02:00
|
|
|
|
2006-04-12 23:46:44 +02:00
|
|
|
if (thd->stmt_map.insert(thd, stmt))
|
2004-03-02 20:39:50 +01:00
|
|
|
{
|
2006-04-07 21:37:06 +02:00
|
|
|
/*
|
2006-04-12 16:30:54 +02:00
|
|
|
The error is set in the insert. The statement itself
|
2006-04-07 21:37:06 +02:00
|
|
|
will be also deleted there (this is how the hash works).
|
|
|
|
*/
|
2006-04-12 16:30:54 +02:00
|
|
|
DBUG_VOID_RETURN;
|
2004-03-02 20:39:50 +01:00
|
|
|
}
|
2003-01-03 12:52:53 +01:00
|
|
|
|
2004-10-26 18:30:01 +02:00
|
|
|
/* Reset warnings from previous command */
|
2005-03-16 15:11:01 +01:00
|
|
|
mysql_reset_errors(thd, 0);
|
2005-08-10 23:17:02 +02:00
|
|
|
sp_cache_flush_obsolete(&thd->sp_proc_cache);
|
|
|
|
sp_cache_flush_obsolete(&thd->sp_func_cache);
|
|
|
|
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
if (!(specialflag & SPECIAL_NO_PRIOR))
|
|
|
|
my_pthread_setprio(pthread_self(),QUERY_PRIOR);
|
2004-08-21 00:02:46 +02:00
|
|
|
|
2005-10-06 16:54:43 +02:00
|
|
|
error= stmt->prepare(packet, packet_length);
|
2002-06-12 23:13:12 +02:00
|
|
|
|
|
|
|
if (!(specialflag & SPECIAL_NO_PRIOR))
|
2002-11-22 19:04:42 +01:00
|
|
|
my_pthread_setprio(pthread_self(),WAIT_PRIOR);
|
2002-06-12 23:13:12 +02:00
|
|
|
|
2005-10-06 16:54:43 +02:00
|
|
|
if (error)
|
2002-10-02 12:33:08 +02:00
|
|
|
{
|
2004-03-02 20:39:50 +01:00
|
|
|
/* Statement map deletes statement on erase */
|
|
|
|
thd->stmt_map.erase(stmt);
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
mysql_log.write(thd, COM_STMT_PREPARE, "[%lu] %s", stmt->id, packet);
|
|
|
|
|
|
|
|
/* check_prepared_statemnt sends the metadata packet in case of success */
|
|
|
|
DBUG_VOID_RETURN;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
SYNOPSIS
|
|
|
|
get_dynamic_sql_string()
|
|
|
|
lex in main lex
|
|
|
|
query_len out length of the SQL statement (is set only
|
|
|
|
in case of success)
|
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
Get an SQL statement text from a user variable or from plain
|
|
|
|
text. If the statement is plain text, just assign the
|
|
|
|
pointers, otherwise allocate memory in thd->mem_root and copy
|
|
|
|
the contents of the variable, possibly with character
|
|
|
|
set conversion.
|
|
|
|
|
|
|
|
RETURN VALUE
|
|
|
|
non-zero success, 0 in case of error (out of memory)
|
|
|
|
*/
|
|
|
|
|
|
|
|
static const char *get_dynamic_sql_string(LEX *lex, uint *query_len)
|
|
|
|
{
|
|
|
|
THD *thd= lex->thd;
|
|
|
|
char *query_str= 0;
|
|
|
|
|
|
|
|
if (lex->prepared_stmt_code_is_varref)
|
|
|
|
{
|
|
|
|
/* This is PREPARE stmt FROM or EXECUTE IMMEDIATE @var. */
|
|
|
|
String str;
|
|
|
|
CHARSET_INFO *to_cs= thd->variables.collation_connection;
|
|
|
|
bool needs_conversion;
|
|
|
|
user_var_entry *entry;
|
2005-10-06 16:54:43 +02:00
|
|
|
String *var_value= &str;
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
uint32 unused, len;
|
|
|
|
/*
|
|
|
|
Convert @var contents to string in connection character set. Although
|
|
|
|
it is known that int/real/NULL value cannot be a valid query we still
|
|
|
|
convert it for error messages to be uniform.
|
|
|
|
*/
|
|
|
|
if ((entry=
|
|
|
|
(user_var_entry*)hash_search(&thd->user_vars,
|
|
|
|
(byte*)lex->prepared_stmt_code.str,
|
|
|
|
lex->prepared_stmt_code.length))
|
|
|
|
&& entry->value)
|
|
|
|
{
|
|
|
|
my_bool is_var_null;
|
2005-10-06 16:54:43 +02:00
|
|
|
var_value= entry->val_str(&is_var_null, &str, NOT_FIXED_DEC);
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
/*
|
|
|
|
NULL value of variable checked early as entry->value so here
|
|
|
|
we can't get NULL in normal conditions
|
|
|
|
*/
|
|
|
|
DBUG_ASSERT(!is_var_null);
|
2005-10-06 16:54:43 +02:00
|
|
|
if (!var_value)
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
goto end;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
variable absent or equal to NULL, so we need to set variable to
|
|
|
|
something reasonable to get a readable error message during parsing
|
|
|
|
*/
|
2005-11-20 19:47:07 +01:00
|
|
|
str.set(STRING_WITH_LEN("NULL"), &my_charset_latin1);
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
}
|
|
|
|
|
2005-10-06 16:54:43 +02:00
|
|
|
needs_conversion= String::needs_conversion(var_value->length(),
|
|
|
|
var_value->charset(), to_cs,
|
|
|
|
&unused);
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
|
2005-10-06 16:54:43 +02:00
|
|
|
len= (needs_conversion ? var_value->length() * to_cs->mbmaxlen :
|
|
|
|
var_value->length());
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
if (!(query_str= alloc_root(thd->mem_root, len+1)))
|
|
|
|
goto end;
|
|
|
|
|
|
|
|
if (needs_conversion)
|
|
|
|
{
|
|
|
|
uint dummy_errors;
|
2005-10-06 16:54:43 +02:00
|
|
|
len= copy_and_convert(query_str, len, to_cs, var_value->ptr(),
|
|
|
|
var_value->length(), var_value->charset(),
|
|
|
|
&dummy_errors);
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
}
|
|
|
|
else
|
2005-10-06 16:54:43 +02:00
|
|
|
memcpy(query_str, var_value->ptr(), var_value->length());
|
|
|
|
query_str[len]= '\0'; // Safety (mostly for debug)
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
*query_len= len;
|
2006-05-08 01:14:43 +02:00
|
|
|
}
|
2004-03-02 20:39:50 +01:00
|
|
|
else
|
2004-07-15 03:19:07 +02:00
|
|
|
{
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
query_str= lex->prepared_stmt_code.str;
|
|
|
|
*query_len= lex->prepared_stmt_code.length;
|
2004-07-15 03:19:07 +02:00
|
|
|
}
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
end:
|
|
|
|
return query_str;
|
2002-06-12 23:13:12 +02:00
|
|
|
}
|
|
|
|
|
2004-11-03 11:39:38 +01:00
|
|
|
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
/* Init PS/SP specific parse tree members. */
|
2005-03-03 15:38:59 +01:00
|
|
|
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
static void init_stmt_after_parse(LEX *lex)
|
2005-03-03 15:38:59 +01:00
|
|
|
{
|
|
|
|
SELECT_LEX *sl= lex->all_selects_list;
|
2005-07-13 16:05:57 +02:00
|
|
|
/*
|
|
|
|
Switch off a temporary flag that prevents evaluation of
|
|
|
|
subqueries in statement prepare.
|
|
|
|
*/
|
2005-07-01 06:05:42 +02:00
|
|
|
for (; sl; sl= sl->next_select_in_list())
|
|
|
|
sl->uncacheable&= ~UNCACHEABLE_PREPARE;
|
2005-03-03 15:38:59 +01:00
|
|
|
}
|
|
|
|
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
/*
|
|
|
|
SQLCOM_PREPARE implementation.
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
mysql_sql_stmt_prepare()
|
|
|
|
thd thread handle
|
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
Prepare an SQL prepared statement. This is called from
|
|
|
|
mysql_execute_command and should therefore behave like an
|
|
|
|
ordinary query (e.g. should not reset any global THD data).
|
|
|
|
|
|
|
|
RETURN VALUE
|
|
|
|
none: in case of success, OK packet is sent to the client,
|
|
|
|
otherwise an error message is set in THD
|
|
|
|
*/
|
|
|
|
|
|
|
|
void mysql_sql_stmt_prepare(THD *thd)
|
|
|
|
{
|
|
|
|
LEX *lex= thd->lex;
|
|
|
|
LEX_STRING *name= &lex->prepared_stmt_name;
|
|
|
|
Prepared_statement *stmt;
|
|
|
|
const char *query;
|
|
|
|
uint query_len;
|
|
|
|
DBUG_ENTER("mysql_sql_stmt_prepare");
|
|
|
|
DBUG_ASSERT(thd->protocol == &thd->protocol_simple);
|
2005-10-06 16:54:43 +02:00
|
|
|
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
if ((stmt= (Prepared_statement*) thd->stmt_map.find_by_name(name)))
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
If there is a statement with the same name, remove it. It is ok to
|
|
|
|
remove old and fail to insert a new one at the same time.
|
|
|
|
*/
|
|
|
|
if (stmt->deallocate())
|
|
|
|
DBUG_VOID_RETURN;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (! (query= get_dynamic_sql_string(lex, &query_len)) ||
|
|
|
|
! (stmt= new Prepared_statement(thd, &thd->protocol_simple)))
|
|
|
|
{
|
|
|
|
DBUG_VOID_RETURN; /* out of memory */
|
|
|
|
}
|
|
|
|
|
2006-04-12 23:46:44 +02:00
|
|
|
/* Set the name first, insert should know that this statement has a name */
|
|
|
|
if (stmt->set_name(name))
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
{
|
2006-04-12 23:46:44 +02:00
|
|
|
delete stmt;
|
2006-04-12 16:30:54 +02:00
|
|
|
DBUG_VOID_RETURN;
|
|
|
|
}
|
2006-04-12 23:46:44 +02:00
|
|
|
if (thd->stmt_map.insert(thd, stmt))
|
2006-04-12 16:30:54 +02:00
|
|
|
{
|
2006-04-12 23:46:44 +02:00
|
|
|
/* The statement is deleted and an error is set if insert fails */
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
DBUG_VOID_RETURN;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (stmt->prepare(query, query_len+1))
|
|
|
|
{
|
|
|
|
/* Statement map deletes the statement on erase */
|
|
|
|
thd->stmt_map.erase(stmt);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
send_ok(thd, 0L, 0L, "Statement prepared");
|
|
|
|
|
|
|
|
DBUG_VOID_RETURN;
|
|
|
|
}
|
2005-03-03 15:38:59 +01:00
|
|
|
|
|
|
|
/* Reinit prepared statement/stored procedure before execution */
|
2002-06-12 23:13:12 +02:00
|
|
|
|
2005-06-09 16:17:45 +02:00
|
|
|
void reinit_stmt_before_use(THD *thd, LEX *lex)
|
2004-03-02 20:39:50 +01:00
|
|
|
{
|
2004-05-20 01:02:49 +02:00
|
|
|
SELECT_LEX *sl= lex->all_selects_list;
|
2005-06-09 16:17:45 +02:00
|
|
|
DBUG_ENTER("reinit_stmt_before_use");
|
2002-06-12 23:13:12 +02:00
|
|
|
|
2005-08-09 22:23:56 +02:00
|
|
|
/*
|
|
|
|
We have to update "thd" pointer in LEX, all its units and in LEX::result,
|
|
|
|
since statements which belong to trigger body are associated with TABLE
|
|
|
|
object and because of this can be used in different threads.
|
|
|
|
*/
|
|
|
|
lex->thd= thd;
|
|
|
|
|
2004-07-16 00:15:55 +02:00
|
|
|
if (lex->empty_field_list_on_rset)
|
|
|
|
{
|
|
|
|
lex->empty_field_list_on_rset= 0;
|
2004-09-03 20:43:04 +02:00
|
|
|
lex->field_list.empty();
|
2004-07-16 00:15:55 +02:00
|
|
|
}
|
2004-03-02 20:39:50 +01:00
|
|
|
for (; sl; sl= sl->next_select_in_list())
|
2003-09-02 18:56:55 +02:00
|
|
|
{
|
2004-05-20 01:02:49 +02:00
|
|
|
if (!sl->first_execution)
|
|
|
|
{
|
2004-07-07 10:29:39 +02:00
|
|
|
/* remove option which was put by mysql_explain_union() */
|
|
|
|
sl->options&= ~SELECT_DESCRIBE;
|
|
|
|
|
2005-03-28 14:13:31 +02:00
|
|
|
/* see unique_table() */
|
|
|
|
sl->exclude_from_table_unique_test= FALSE;
|
|
|
|
|
2004-05-20 01:02:49 +02:00
|
|
|
/*
|
2006-05-08 01:14:43 +02:00
|
|
|
Copy WHERE, HAVING clause pointers to avoid damaging them
|
|
|
|
by optimisation
|
2004-05-20 01:02:49 +02:00
|
|
|
*/
|
2006-05-08 01:14:43 +02:00
|
|
|
if (sl->prep_where)
|
|
|
|
{
|
|
|
|
sl->where= sl->prep_where->copy_andor_structure(thd);
|
|
|
|
sl->where->cleanup();
|
|
|
|
}
|
|
|
|
if (sl->prep_having)
|
|
|
|
{
|
|
|
|
sl->having= sl->prep_having->copy_andor_structure(thd);
|
|
|
|
sl->having->cleanup();
|
|
|
|
}
|
|
|
|
DBUG_ASSERT(sl->join == 0);
|
2004-05-20 01:02:49 +02:00
|
|
|
ORDER *order;
|
|
|
|
/* Fix GROUP list */
|
|
|
|
for (order= (ORDER *)sl->group_list.first; order; order= order->next)
|
|
|
|
order->item= &order->item_ptr;
|
|
|
|
/* Fix ORDER list */
|
|
|
|
for (order= (ORDER *)sl->order_list.first; order; order= order->next)
|
|
|
|
order->item= &order->item_ptr;
|
2006-05-08 01:14:43 +02:00
|
|
|
}
|
2004-02-12 17:50:00 +01:00
|
|
|
{
|
|
|
|
SELECT_LEX_UNIT *unit= sl->master_unit();
|
|
|
|
unit->unclean();
|
|
|
|
unit->types.empty();
|
2004-03-02 20:39:50 +01:00
|
|
|
/* for derived tables & PS (which can't be reset by Item_subquery) */
|
2004-02-12 17:50:00 +01:00
|
|
|
unit->reinit_exec_mechanism();
|
2005-08-09 22:23:56 +02:00
|
|
|
unit->set_thd(thd);
|
2004-02-12 17:50:00 +01:00
|
|
|
}
|
2003-09-02 18:56:55 +02:00
|
|
|
}
|
2004-07-16 00:15:55 +02:00
|
|
|
|
|
|
|
/*
|
2005-06-08 17:57:26 +02:00
|
|
|
TODO: When the new table structure is ready, then have a status bit
|
|
|
|
to indicate the table is altered, and re-do the setup_*
|
2004-07-16 00:15:55 +02:00
|
|
|
and open the tables back.
|
|
|
|
*/
|
2005-03-04 14:35:28 +01:00
|
|
|
/*
|
|
|
|
NOTE: We should reset whole table list here including all tables added
|
|
|
|
by prelocking algorithm (it is not a problem for substatements since
|
|
|
|
they have their own table list).
|
|
|
|
*/
|
2004-07-16 00:15:55 +02:00
|
|
|
for (TABLE_LIST *tables= lex->query_tables;
|
2005-06-08 17:57:26 +02:00
|
|
|
tables;
|
|
|
|
tables= tables->next_global)
|
2004-07-16 00:15:55 +02:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
Reset old pointers to TABLEs: they are not valid since the tables
|
|
|
|
were closed in the end of previous prepare or execute call.
|
|
|
|
*/
|
2006-07-06 21:59:04 +02:00
|
|
|
tables->reinit_before_use(thd);
|
2006-07-14 01:35:25 +02:00
|
|
|
|
2006-01-24 13:48:19 +01:00
|
|
|
/* Reset is_schema_table_processed value(needed for I_S tables */
|
|
|
|
tables->is_schema_table_processed= FALSE;
|
2005-03-03 15:38:59 +01:00
|
|
|
|
2006-03-30 02:45:29 +02:00
|
|
|
TABLE_LIST *embedded; /* The table at the current level of nesting. */
|
|
|
|
TABLE_LIST *embedding= tables; /* The parent nested table reference. */
|
|
|
|
do
|
2005-03-03 15:38:59 +01:00
|
|
|
{
|
2006-03-30 02:45:29 +02:00
|
|
|
embedded= embedding;
|
|
|
|
if (embedded->prep_on_expr)
|
|
|
|
embedded->on_expr= embedded->prep_on_expr->copy_andor_structure(thd);
|
|
|
|
embedding= embedded->embedding;
|
2005-03-03 15:38:59 +01:00
|
|
|
}
|
2006-03-30 02:45:29 +02:00
|
|
|
while (embedding &&
|
|
|
|
embedding->nested_join->join_list.head() == embedded);
|
2004-07-16 00:15:55 +02:00
|
|
|
}
|
2004-07-01 00:52:05 +02:00
|
|
|
lex->current_select= &lex->select_lex;
|
2004-09-14 18:28:29 +02:00
|
|
|
|
|
|
|
/* restore original list used in INSERT ... SELECT */
|
|
|
|
if (lex->leaf_tables_insert)
|
|
|
|
lex->select_lex.leaf_tables= lex->leaf_tables_insert;
|
|
|
|
|
2004-08-24 18:17:11 +02:00
|
|
|
if (lex->result)
|
2005-08-09 22:23:56 +02:00
|
|
|
{
|
2004-08-24 18:17:11 +02:00
|
|
|
lex->result->cleanup();
|
2005-08-09 22:23:56 +02:00
|
|
|
lex->result->set_thd(thd);
|
|
|
|
}
|
2005-10-15 23:32:37 +02:00
|
|
|
lex->allow_sum_func= 0;
|
|
|
|
lex->in_sum_func= NULL;
|
2005-09-22 00:38:14 +02:00
|
|
|
DBUG_VOID_RETURN;
|
2004-03-02 20:39:50 +01:00
|
|
|
}
|
|
|
|
|
2004-05-04 17:08:19 +02:00
|
|
|
|
2005-05-16 12:34:23 +02:00
|
|
|
/*
|
|
|
|
Clears parameters from data left from previous execution or long data
|
2005-06-08 17:57:26 +02:00
|
|
|
|
2004-05-04 17:08:19 +02:00
|
|
|
SYNOPSIS
|
|
|
|
reset_stmt_params()
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
stmt prepared statement for which parameters should
|
|
|
|
be reset
|
2004-05-04 17:08:19 +02:00
|
|
|
*/
|
|
|
|
|
|
|
|
static void reset_stmt_params(Prepared_statement *stmt)
|
|
|
|
{
|
|
|
|
Item_param **item= stmt->param_array;
|
|
|
|
Item_param **end= item + stmt->param_count;
|
|
|
|
for (;item < end ; ++item)
|
|
|
|
(**item).reset();
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2004-03-02 20:39:50 +01:00
|
|
|
/*
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
COM_STMT_EXECUTE handler: execute a previously prepared statement.
|
2005-05-16 12:34:23 +02:00
|
|
|
|
2004-06-07 10:09:10 +02:00
|
|
|
SYNOPSIS
|
2004-03-02 20:39:50 +01:00
|
|
|
mysql_stmt_execute()
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
thd current thread
|
|
|
|
packet parameter types and data, if any
|
|
|
|
packet_length packet length, including the terminator character.
|
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
If there are any parameters, then replace parameter markers with the
|
|
|
|
data supplied from the client, and then execute the statement.
|
|
|
|
This function uses binary protocol to send a possible result set
|
|
|
|
to the client.
|
|
|
|
|
|
|
|
RETURN VALUE
|
|
|
|
none: in case of success OK packet or a result set is sent to the
|
|
|
|
client, otherwise an error message is set in THD.
|
2002-06-12 23:13:12 +02:00
|
|
|
*/
|
|
|
|
|
2005-10-26 14:14:08 +02:00
|
|
|
void mysql_stmt_execute(THD *thd, char *packet_arg, uint packet_length)
|
2002-06-12 23:13:12 +02:00
|
|
|
{
|
2005-10-26 14:14:08 +02:00
|
|
|
uchar *packet= (uchar*)packet_arg; // GCC 4.0.1 workaround
|
2003-10-15 21:40:36 +02:00
|
|
|
ulong stmt_id= uint4korr(packet);
|
2004-08-03 12:32:21 +02:00
|
|
|
ulong flags= (ulong) ((uchar) packet[4]);
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
/* Query text for binary, general or slow log, if any of them is open */
|
2004-06-07 10:09:10 +02:00
|
|
|
String expanded_query;
|
2004-04-05 12:56:05 +02:00
|
|
|
#ifndef EMBEDDED_LIBRARY
|
2004-03-31 00:27:49 +02:00
|
|
|
uchar *packet_end= (uchar *) packet + packet_length - 1;
|
2004-04-05 12:56:05 +02:00
|
|
|
#endif
|
2003-12-20 00:16:10 +01:00
|
|
|
Prepared_statement *stmt;
|
2005-10-06 16:54:43 +02:00
|
|
|
bool error;
|
2003-12-20 00:16:10 +01:00
|
|
|
DBUG_ENTER("mysql_stmt_execute");
|
2004-03-31 00:27:49 +02:00
|
|
|
|
|
|
|
packet+= 9; /* stmt_id + 5 bytes of flags */
|
2004-06-07 10:09:10 +02:00
|
|
|
|
2005-11-17 17:40:48 +01:00
|
|
|
/* First of all clear possible warnings from the previous command */
|
|
|
|
mysql_reset_thd_for_next_command(thd);
|
|
|
|
|
2004-10-20 03:04:37 +02:00
|
|
|
if (!(stmt= find_prepared_statement(thd, stmt_id, "mysql_stmt_execute")))
|
2002-10-02 12:33:08 +02:00
|
|
|
DBUG_VOID_RETURN;
|
|
|
|
|
2005-07-29 04:06:35 +02:00
|
|
|
DBUG_PRINT("exec_query", ("%s", stmt->query));
|
|
|
|
DBUG_PRINT("info",("stmt: %p", stmt));
|
2004-04-03 10:13:51 +02:00
|
|
|
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
sp_cache_flush_obsolete(&thd->sp_proc_cache);
|
|
|
|
sp_cache_flush_obsolete(&thd->sp_func_cache);
|
|
|
|
|
2003-09-17 17:48:53 +02:00
|
|
|
#ifndef EMBEDDED_LIBRARY
|
2004-03-02 20:39:50 +01:00
|
|
|
if (stmt->param_count)
|
2003-09-02 18:56:55 +02:00
|
|
|
{
|
2004-03-02 20:39:50 +01:00
|
|
|
uchar *null_array= (uchar *) packet;
|
2004-03-15 18:20:47 +01:00
|
|
|
if (setup_conversion_functions(stmt, (uchar **) &packet, packet_end) ||
|
2004-05-24 19:08:22 +02:00
|
|
|
stmt->set_params(stmt, null_array, (uchar *) packet, packet_end,
|
2004-06-07 10:09:10 +02:00
|
|
|
&expanded_query))
|
2004-03-02 20:39:50 +01:00
|
|
|
goto set_params_data_err;
|
2003-09-02 18:56:55 +02:00
|
|
|
}
|
2003-09-17 17:48:53 +02:00
|
|
|
#else
|
2003-12-20 00:16:10 +01:00
|
|
|
/*
|
2005-06-08 17:57:26 +02:00
|
|
|
In embedded library we re-install conversion routines each time
|
|
|
|
we set params, and also we don't need to parse packet.
|
2004-03-02 20:39:50 +01:00
|
|
|
So we do it in one function.
|
2003-12-20 00:16:10 +01:00
|
|
|
*/
|
2004-06-01 15:27:40 +02:00
|
|
|
if (stmt->param_count && stmt->set_params_data(stmt, &expanded_query))
|
2004-03-02 20:39:50 +01:00
|
|
|
goto set_params_data_err;
|
2003-09-17 17:48:53 +02:00
|
|
|
#endif
|
2004-08-03 12:32:21 +02:00
|
|
|
if (!(specialflag & SPECIAL_NO_PRIOR))
|
|
|
|
my_pthread_setprio(pthread_self(),QUERY_PRIOR);
|
2005-10-06 16:54:43 +02:00
|
|
|
error= stmt->execute(&expanded_query,
|
2005-10-08 02:37:23 +02:00
|
|
|
test(flags & (ulong) CURSOR_TYPE_READ_ONLY));
|
2004-08-03 12:32:21 +02:00
|
|
|
if (!(specialflag & SPECIAL_NO_PRIOR))
|
|
|
|
my_pthread_setprio(pthread_self(), WAIT_PRIOR);
|
2005-10-08 02:37:23 +02:00
|
|
|
if (error == 0)
|
2005-09-22 00:11:21 +02:00
|
|
|
mysql_log.write(thd, COM_STMT_EXECUTE, "[%lu] %s", stmt->id, thd->query);
|
2005-07-27 12:45:32 +02:00
|
|
|
|
2004-03-02 20:39:50 +01:00
|
|
|
DBUG_VOID_RETURN;
|
2002-11-22 19:04:42 +01:00
|
|
|
|
2004-03-02 20:39:50 +01:00
|
|
|
set_params_data_err:
|
2004-05-25 06:15:50 +02:00
|
|
|
my_error(ER_WRONG_ARGUMENTS, MYF(0), "mysql_stmt_execute");
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
reset_stmt_params(stmt);
|
2002-06-12 23:13:12 +02:00
|
|
|
DBUG_VOID_RETURN;
|
|
|
|
}
|
|
|
|
|
2002-10-02 12:33:08 +02:00
|
|
|
|
2004-04-05 17:43:37 +02:00
|
|
|
/*
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
SQLCOM_EXECUTE implementation.
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
mysql_sql_stmt_execute()
|
|
|
|
thd thread handle
|
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
Execute prepared statement using parameter values from
|
|
|
|
lex->prepared_stmt_params and send result to the client using
|
|
|
|
text protocol. This is called from mysql_execute_command and
|
|
|
|
therefore should behave like an ordinary query (e.g. not change
|
|
|
|
global THD data, such as warning count, server status, etc).
|
|
|
|
This function uses text protocol to send a possible result set.
|
|
|
|
|
|
|
|
RETURN
|
|
|
|
none: in case of success, OK (or result set) packet is sent to the
|
|
|
|
client, otherwise an error is set in THD
|
2004-04-05 17:43:37 +02:00
|
|
|
*/
|
|
|
|
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
void mysql_sql_stmt_execute(THD *thd)
|
2004-04-05 17:43:37 +02:00
|
|
|
{
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
LEX *lex= thd->lex;
|
2004-04-12 23:58:48 +02:00
|
|
|
Prepared_statement *stmt;
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
LEX_STRING *name= &lex->prepared_stmt_name;
|
|
|
|
/* Query text for binary, general or slow log, if any of them is open */
|
2004-05-24 19:08:22 +02:00
|
|
|
String expanded_query;
|
2004-05-21 02:27:50 +02:00
|
|
|
DBUG_ENTER("mysql_sql_stmt_execute");
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
DBUG_PRINT("info", ("EXECUTE: %.*s\n", name->length, name->str));
|
2004-09-09 05:59:26 +02:00
|
|
|
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
if (!(stmt= (Prepared_statement*) thd->stmt_map.find_by_name(name)))
|
2004-04-12 23:58:48 +02:00
|
|
|
{
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
my_error(ER_UNKNOWN_STMT_HANDLER, MYF(0),
|
|
|
|
name->length, name->str, "EXECUTE");
|
2004-05-21 02:27:50 +02:00
|
|
|
DBUG_VOID_RETURN;
|
2004-04-12 23:58:48 +02:00
|
|
|
}
|
|
|
|
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
if (stmt->param_count != lex->prepared_stmt_params.elements)
|
2004-04-05 17:43:37 +02:00
|
|
|
{
|
2004-06-07 10:09:10 +02:00
|
|
|
my_error(ER_WRONG_ARGUMENTS, MYF(0), "EXECUTE");
|
2004-04-05 17:43:37 +02:00
|
|
|
DBUG_VOID_RETURN;
|
|
|
|
}
|
|
|
|
|
2005-07-29 04:06:35 +02:00
|
|
|
DBUG_PRINT("info",("stmt: %p", stmt));
|
|
|
|
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
if (stmt->set_params_from_vars(stmt, lex->prepared_stmt_params,
|
2004-05-24 19:08:22 +02:00
|
|
|
&expanded_query))
|
2005-09-22 00:11:21 +02:00
|
|
|
goto set_params_data_err;
|
2002-10-02 12:33:08 +02:00
|
|
|
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
(void) stmt->execute(&expanded_query, FALSE);
|
2004-09-15 21:10:31 +02:00
|
|
|
|
2002-06-12 23:13:12 +02:00
|
|
|
DBUG_VOID_RETURN;
|
2005-09-22 00:11:21 +02:00
|
|
|
|
|
|
|
set_params_data_err:
|
|
|
|
my_error(ER_WRONG_ARGUMENTS, MYF(0), "EXECUTE");
|
|
|
|
reset_stmt_params(stmt);
|
|
|
|
DBUG_VOID_RETURN;
|
2002-06-12 23:13:12 +02:00
|
|
|
}
|
|
|
|
|
2002-10-02 12:33:08 +02:00
|
|
|
|
2004-08-03 12:32:21 +02:00
|
|
|
/*
|
2005-06-17 21:26:25 +02:00
|
|
|
COM_STMT_FETCH handler: fetches requested amount of rows from cursor
|
2004-11-09 02:58:44 +01:00
|
|
|
|
2004-08-03 12:32:21 +02:00
|
|
|
SYNOPSIS
|
2004-11-09 02:58:44 +01:00
|
|
|
mysql_stmt_fetch()
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
thd Thread handle
|
|
|
|
packet Packet from client (with stmt_id & num_rows)
|
|
|
|
packet_length Length of packet
|
2004-08-03 12:32:21 +02:00
|
|
|
*/
|
|
|
|
|
|
|
|
void mysql_stmt_fetch(THD *thd, char *packet, uint packet_length)
|
|
|
|
{
|
|
|
|
/* assume there is always place for 8-16 bytes */
|
|
|
|
ulong stmt_id= uint4korr(packet);
|
2005-05-16 12:34:23 +02:00
|
|
|
ulong num_rows= uint4korr(packet+4);
|
2005-06-09 16:17:45 +02:00
|
|
|
Prepared_statement *stmt;
|
2005-06-22 21:12:25 +02:00
|
|
|
Statement stmt_backup;
|
2005-09-22 00:11:21 +02:00
|
|
|
Server_side_cursor *cursor;
|
2004-08-03 12:32:21 +02:00
|
|
|
DBUG_ENTER("mysql_stmt_fetch");
|
|
|
|
|
2005-11-17 17:40:48 +01:00
|
|
|
/* First of all clear possible warnings from the previous command */
|
2005-11-17 14:20:12 +01:00
|
|
|
mysql_reset_thd_for_next_command(thd);
|
2005-06-16 23:58:36 +02:00
|
|
|
statistic_increment(thd->status_var.com_stmt_fetch, &LOCK_status);
|
2005-05-12 09:16:12 +02:00
|
|
|
if (!(stmt= find_prepared_statement(thd, stmt_id, "mysql_stmt_fetch")))
|
|
|
|
DBUG_VOID_RETURN;
|
|
|
|
|
2005-07-01 13:47:45 +02:00
|
|
|
cursor= stmt->cursor;
|
2005-09-22 00:11:21 +02:00
|
|
|
if (!cursor)
|
2004-08-03 12:32:21 +02:00
|
|
|
{
|
2005-06-20 13:38:15 +02:00
|
|
|
my_error(ER_STMT_HAS_NO_OPEN_CURSOR, MYF(0), stmt_id);
|
2004-08-03 12:32:21 +02:00
|
|
|
DBUG_VOID_RETURN;
|
|
|
|
}
|
2005-05-12 09:16:12 +02:00
|
|
|
|
2005-09-02 15:21:19 +02:00
|
|
|
thd->stmt_arena= stmt;
|
2005-06-22 21:12:25 +02:00
|
|
|
thd->set_n_backup_statement(stmt, &stmt_backup);
|
2004-08-03 12:32:21 +02:00
|
|
|
|
|
|
|
if (!(specialflag & SPECIAL_NO_PRIOR))
|
|
|
|
my_pthread_setprio(pthread_self(), QUERY_PRIOR);
|
|
|
|
|
2005-07-01 13:47:45 +02:00
|
|
|
cursor->fetch(num_rows);
|
2004-08-03 12:32:21 +02:00
|
|
|
|
|
|
|
if (!(specialflag & SPECIAL_NO_PRIOR))
|
|
|
|
my_pthread_setprio(pthread_self(), WAIT_PRIOR);
|
|
|
|
|
2005-07-01 13:47:45 +02:00
|
|
|
if (!cursor->is_open())
|
2005-06-09 16:17:45 +02:00
|
|
|
{
|
2005-09-22 00:11:21 +02:00
|
|
|
stmt->close_cursor();
|
|
|
|
thd->cursor= 0;
|
2005-06-09 16:17:45 +02:00
|
|
|
reset_stmt_params(stmt);
|
|
|
|
}
|
|
|
|
|
2005-07-01 13:47:45 +02:00
|
|
|
thd->restore_backup_statement(stmt, &stmt_backup);
|
2005-09-02 15:21:19 +02:00
|
|
|
thd->stmt_arena= thd;
|
2005-07-01 13:47:45 +02:00
|
|
|
|
2004-08-03 12:32:21 +02:00
|
|
|
DBUG_VOID_RETURN;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2002-06-12 23:13:12 +02:00
|
|
|
/*
|
2004-05-24 19:08:22 +02:00
|
|
|
Reset a prepared statement in case there was a recoverable error.
|
2002-10-02 12:33:08 +02:00
|
|
|
SYNOPSIS
|
|
|
|
mysql_stmt_reset()
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
thd Thread handle
|
|
|
|
packet Packet with stmt id
|
2002-10-02 12:33:08 +02:00
|
|
|
|
|
|
|
DESCRIPTION
|
2004-05-06 20:44:00 +02:00
|
|
|
This function resets statement to the state it was right after prepare.
|
|
|
|
It can be used to:
|
|
|
|
- clear an error happened during mysql_stmt_send_long_data
|
|
|
|
- cancel long data stream for all placeholders without
|
|
|
|
having to call mysql_stmt_execute.
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
- close an open cursor
|
2004-05-06 20:44:00 +02:00
|
|
|
Sends 'OK' packet in case of success (statement was reset)
|
|
|
|
or 'ERROR' packet (unrecoverable error/statement not found/etc).
|
2002-06-12 23:13:12 +02:00
|
|
|
*/
|
|
|
|
|
2002-10-02 12:33:08 +02:00
|
|
|
void mysql_stmt_reset(THD *thd, char *packet)
|
2002-06-12 23:13:12 +02:00
|
|
|
{
|
2004-03-15 18:20:47 +01:00
|
|
|
/* There is always space for 4 bytes in buffer */
|
2002-10-02 12:33:08 +02:00
|
|
|
ulong stmt_id= uint4korr(packet);
|
2003-12-20 00:16:10 +01:00
|
|
|
Prepared_statement *stmt;
|
2002-10-02 12:33:08 +02:00
|
|
|
DBUG_ENTER("mysql_stmt_reset");
|
2002-06-12 23:13:12 +02:00
|
|
|
|
2005-11-17 17:40:48 +01:00
|
|
|
/* First of all clear possible warnings from the previous command */
|
|
|
|
mysql_reset_thd_for_next_command(thd);
|
|
|
|
|
2005-06-16 23:58:36 +02:00
|
|
|
statistic_increment(thd->status_var.com_stmt_reset, &LOCK_status);
|
2004-10-20 03:04:37 +02:00
|
|
|
if (!(stmt= find_prepared_statement(thd, stmt_id, "mysql_stmt_reset")))
|
2002-10-02 12:33:08 +02:00
|
|
|
DBUG_VOID_RETURN;
|
|
|
|
|
2005-09-22 00:11:21 +02:00
|
|
|
stmt->close_cursor();
|
|
|
|
|
|
|
|
/*
|
|
|
|
Clear parameters from data which could be set by
|
|
|
|
mysql_stmt_send_long_data() call.
|
|
|
|
*/
|
|
|
|
reset_stmt_params(stmt);
|
2005-05-12 09:16:12 +02:00
|
|
|
|
2005-06-15 19:58:35 +02:00
|
|
|
stmt->state= Query_arena::PREPARED;
|
2002-10-02 12:33:08 +02:00
|
|
|
|
2004-05-06 20:44:00 +02:00
|
|
|
send_ok(thd);
|
2005-06-08 17:57:26 +02:00
|
|
|
|
2002-10-02 12:33:08 +02:00
|
|
|
DBUG_VOID_RETURN;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
2004-03-02 20:39:50 +01:00
|
|
|
Delete a prepared statement from memory.
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
Note: we don't send any reply to this command.
|
2002-10-02 12:33:08 +02:00
|
|
|
*/
|
|
|
|
|
2005-06-17 21:26:25 +02:00
|
|
|
void mysql_stmt_close(THD *thd, char *packet)
|
2002-10-02 12:33:08 +02:00
|
|
|
{
|
2004-03-15 18:20:47 +01:00
|
|
|
/* There is always space for 4 bytes in packet buffer */
|
2002-10-02 12:33:08 +02:00
|
|
|
ulong stmt_id= uint4korr(packet);
|
2003-12-20 00:16:10 +01:00
|
|
|
Prepared_statement *stmt;
|
2005-06-17 21:26:25 +02:00
|
|
|
DBUG_ENTER("mysql_stmt_close");
|
2002-10-02 12:33:08 +02:00
|
|
|
|
2004-10-20 03:04:37 +02:00
|
|
|
if (!(stmt= find_prepared_statement(thd, stmt_id, "mysql_stmt_close")))
|
2002-10-02 12:33:08 +02:00
|
|
|
DBUG_VOID_RETURN;
|
2003-12-20 00:16:10 +01:00
|
|
|
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
/*
|
|
|
|
The only way currently a statement can be deallocated when it's
|
|
|
|
in use is from within Dynamic SQL.
|
|
|
|
*/
|
2005-10-06 16:54:43 +02:00
|
|
|
DBUG_ASSERT(! (stmt->flags & (uint) Prepared_statement::IS_IN_USE));
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
(void) stmt->deallocate();
|
|
|
|
|
2002-06-12 23:13:12 +02:00
|
|
|
DBUG_VOID_RETURN;
|
|
|
|
}
|
|
|
|
|
2002-10-02 12:33:08 +02:00
|
|
|
|
|
|
|
/*
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
SQLCOM_DEALLOCATE implementation.
|
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
Close an SQL prepared statement. As this can be called from Dynamic
|
|
|
|
SQL, we should be careful to not close a statement that is currently
|
|
|
|
being executed.
|
|
|
|
|
|
|
|
RETURN VALUE
|
|
|
|
none: OK packet is sent in case of success, otherwise an error
|
|
|
|
message is set in THD
|
|
|
|
*/
|
|
|
|
|
|
|
|
void mysql_sql_stmt_close(THD *thd)
|
|
|
|
{
|
|
|
|
Prepared_statement* stmt;
|
|
|
|
LEX_STRING *name= &thd->lex->prepared_stmt_name;
|
|
|
|
DBUG_PRINT("info", ("DEALLOCATE PREPARE: %.*s\n", name->length, name->str));
|
|
|
|
|
|
|
|
if (! (stmt= (Prepared_statement*) thd->stmt_map.find_by_name(name)))
|
|
|
|
{
|
|
|
|
my_error(ER_UNKNOWN_STMT_HANDLER, MYF(0),
|
|
|
|
name->length, name->str, "DEALLOCATE PREPARE");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (stmt->deallocate() == 0)
|
|
|
|
send_ok(thd);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
Handle long data in pieces from client.
|
2002-10-02 12:33:08 +02:00
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
mysql_stmt_get_longdata()
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
thd Thread handle
|
|
|
|
packet String to append
|
2005-10-06 16:54:43 +02:00
|
|
|
packet_length Length of string (including end \0)
|
2002-10-02 12:33:08 +02:00
|
|
|
|
|
|
|
DESCRIPTION
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
Get a part of a long data. To make the protocol efficient, we are
|
|
|
|
not sending any return packets here. If something goes wrong, then
|
|
|
|
we will send the error on 'execute' We assume that the client takes
|
|
|
|
care of checking that all parts are sent to the server. (No checking
|
|
|
|
that we get a 'end of column' in the server is performed).
|
2002-10-02 12:33:08 +02:00
|
|
|
*/
|
|
|
|
|
2004-05-25 00:03:49 +02:00
|
|
|
void mysql_stmt_get_longdata(THD *thd, char *packet, ulong packet_length)
|
2002-10-02 12:33:08 +02:00
|
|
|
{
|
2004-05-25 00:03:49 +02:00
|
|
|
ulong stmt_id;
|
|
|
|
uint param_number;
|
2003-12-20 00:16:10 +01:00
|
|
|
Prepared_statement *stmt;
|
2004-05-25 00:03:49 +02:00
|
|
|
Item_param *param;
|
|
|
|
char *packet_end= packet + packet_length - 1;
|
2002-10-02 12:33:08 +02:00
|
|
|
DBUG_ENTER("mysql_stmt_get_longdata");
|
|
|
|
|
2005-06-16 23:58:36 +02:00
|
|
|
statistic_increment(thd->status_var.com_stmt_send_long_data, &LOCK_status);
|
2003-10-06 13:32:38 +02:00
|
|
|
#ifndef EMBEDDED_LIBRARY
|
2004-05-25 00:03:49 +02:00
|
|
|
/* Minimal size of long data packet is 6 bytes */
|
2005-10-06 16:54:43 +02:00
|
|
|
if (packet_length <= MYSQL_LONG_DATA_HEADER)
|
2002-10-02 12:33:08 +02:00
|
|
|
{
|
2004-05-25 00:03:49 +02:00
|
|
|
my_error(ER_WRONG_ARGUMENTS, MYF(0), "mysql_stmt_send_long_data");
|
2002-10-02 12:33:08 +02:00
|
|
|
DBUG_VOID_RETURN;
|
|
|
|
}
|
2003-10-06 13:32:38 +02:00
|
|
|
#endif
|
2002-10-02 12:33:08 +02:00
|
|
|
|
2004-05-25 00:03:49 +02:00
|
|
|
stmt_id= uint4korr(packet);
|
|
|
|
packet+= 4;
|
2002-10-02 12:33:08 +02:00
|
|
|
|
2004-10-20 03:04:37 +02:00
|
|
|
if (!(stmt=find_prepared_statement(thd, stmt_id,
|
|
|
|
"mysql_stmt_send_long_data")))
|
2002-10-02 12:33:08 +02:00
|
|
|
DBUG_VOID_RETURN;
|
|
|
|
|
2004-05-25 00:03:49 +02:00
|
|
|
param_number= uint2korr(packet);
|
|
|
|
packet+= 2;
|
2003-10-06 13:32:38 +02:00
|
|
|
#ifndef EMBEDDED_LIBRARY
|
2002-10-02 12:33:08 +02:00
|
|
|
if (param_number >= stmt->param_count)
|
|
|
|
{
|
2002-12-07 08:39:11 +01:00
|
|
|
/* Error will be sent in execute call */
|
2005-06-15 19:58:35 +02:00
|
|
|
stmt->state= Query_arena::ERROR;
|
2002-12-07 08:39:11 +01:00
|
|
|
stmt->last_errno= ER_WRONG_ARGUMENTS;
|
2004-05-25 00:03:49 +02:00
|
|
|
sprintf(stmt->last_error, ER(ER_WRONG_ARGUMENTS),
|
|
|
|
"mysql_stmt_send_long_data");
|
2002-10-02 12:33:08 +02:00
|
|
|
DBUG_VOID_RETURN;
|
|
|
|
}
|
2003-10-06 13:32:38 +02:00
|
|
|
#endif
|
|
|
|
|
2004-05-25 00:03:49 +02:00
|
|
|
param= stmt->param_array[param_number];
|
|
|
|
|
2003-10-06 13:32:38 +02:00
|
|
|
#ifndef EMBEDDED_LIBRARY
|
2004-08-21 00:02:46 +02:00
|
|
|
if (param->set_longdata(packet, (ulong) (packet_end - packet)))
|
2003-10-06 13:32:38 +02:00
|
|
|
#else
|
2004-08-21 00:02:46 +02:00
|
|
|
if (param->set_longdata(thd->extra_data, thd->extra_length))
|
2003-10-06 13:32:38 +02:00
|
|
|
#endif
|
2004-08-21 00:02:46 +02:00
|
|
|
{
|
2005-06-15 19:58:35 +02:00
|
|
|
stmt->state= Query_arena::ERROR;
|
2004-08-21 00:02:46 +02:00
|
|
|
stmt->last_errno= ER_OUTOFMEMORY;
|
|
|
|
sprintf(stmt->last_error, ER(ER_OUTOFMEMORY), 0);
|
|
|
|
}
|
2002-10-02 12:33:08 +02:00
|
|
|
DBUG_VOID_RETURN;
|
|
|
|
}
|
2002-11-22 19:04:42 +01:00
|
|
|
|
2003-12-20 00:16:10 +01:00
|
|
|
|
2005-09-22 00:11:21 +02:00
|
|
|
/***************************************************************************
|
|
|
|
Select_fetch_protocol_prep
|
|
|
|
****************************************************************************/
|
|
|
|
|
|
|
|
Select_fetch_protocol_prep::Select_fetch_protocol_prep(THD *thd)
|
|
|
|
:protocol(thd)
|
|
|
|
{}
|
|
|
|
|
|
|
|
bool Select_fetch_protocol_prep::send_fields(List<Item> &list, uint flags)
|
|
|
|
{
|
|
|
|
bool rc;
|
|
|
|
Protocol *save_protocol= thd->protocol;
|
|
|
|
|
|
|
|
/*
|
|
|
|
Protocol::send_fields caches the information about column types:
|
|
|
|
this information is later used to send data. Therefore, the same
|
|
|
|
dedicated Protocol object must be used for all operations with
|
|
|
|
a cursor.
|
|
|
|
*/
|
|
|
|
thd->protocol= &protocol;
|
|
|
|
rc= select_send::send_fields(list, flags);
|
|
|
|
thd->protocol= save_protocol;
|
|
|
|
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool Select_fetch_protocol_prep::send_eof()
|
|
|
|
{
|
|
|
|
Protocol *save_protocol= thd->protocol;
|
|
|
|
|
|
|
|
thd->protocol= &protocol;
|
|
|
|
::send_eof(thd);
|
|
|
|
thd->protocol= save_protocol;
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
bool
|
|
|
|
Select_fetch_protocol_prep::send_data(List<Item> &fields)
|
|
|
|
{
|
|
|
|
Protocol *save_protocol= thd->protocol;
|
|
|
|
bool rc;
|
|
|
|
|
|
|
|
thd->protocol= &protocol;
|
|
|
|
rc= select_send::send_data(fields);
|
|
|
|
thd->protocol= save_protocol;
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
|
|
|
/***************************************************************************
|
|
|
|
Prepared_statement
|
|
|
|
****************************************************************************/
|
|
|
|
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
Prepared_statement::Prepared_statement(THD *thd_arg, Protocol *protocol_arg)
|
2005-06-22 21:12:25 +02:00
|
|
|
:Statement(INITIALIZED, ++thd_arg->statement_id_counter,
|
|
|
|
thd_arg->variables.query_alloc_block_size,
|
|
|
|
thd_arg->variables.query_prealloc_size),
|
2003-12-20 00:16:10 +01:00
|
|
|
thd(thd_arg),
|
2005-09-22 00:11:21 +02:00
|
|
|
result(thd_arg),
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
protocol(protocol_arg),
|
2004-03-02 20:39:50 +01:00
|
|
|
param_array(0),
|
2003-12-20 00:16:10 +01:00
|
|
|
param_count(0),
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
last_errno(0),
|
2005-10-06 16:54:43 +02:00
|
|
|
flags((uint) IS_IN_USE)
|
2003-12-20 00:16:10 +01:00
|
|
|
{
|
|
|
|
*last_error= '\0';
|
|
|
|
}
|
|
|
|
|
2005-06-16 22:11:48 +02:00
|
|
|
|
2004-06-01 15:27:40 +02:00
|
|
|
void Prepared_statement::setup_set_params()
|
|
|
|
{
|
|
|
|
/* Setup binary logging */
|
2005-06-16 22:11:48 +02:00
|
|
|
if (mysql_bin_log.is_open() && is_update_query(lex->sql_command) ||
|
|
|
|
mysql_log.is_open() || mysql_slow_log.is_open())
|
2003-12-20 00:16:10 +01:00
|
|
|
{
|
2004-06-01 15:27:40 +02:00
|
|
|
set_params_from_vars= insert_params_from_vars_with_log;
|
2003-12-20 00:16:10 +01:00
|
|
|
#ifndef EMBEDDED_LIBRARY
|
2004-03-02 20:39:50 +01:00
|
|
|
set_params= insert_params_withlog;
|
2003-12-20 00:16:10 +01:00
|
|
|
#else
|
2004-03-02 20:39:50 +01:00
|
|
|
set_params_data= emb_insert_params_withlog;
|
2003-12-20 00:16:10 +01:00
|
|
|
#endif
|
|
|
|
}
|
|
|
|
else
|
2004-06-01 15:27:40 +02:00
|
|
|
{
|
|
|
|
set_params_from_vars= insert_params_from_vars;
|
2003-12-20 00:16:10 +01:00
|
|
|
#ifndef EMBEDDED_LIBRARY
|
2004-03-02 20:39:50 +01:00
|
|
|
set_params= insert_params;
|
2003-12-20 00:16:10 +01:00
|
|
|
#else
|
2004-03-02 20:39:50 +01:00
|
|
|
set_params_data= emb_insert_params;
|
2003-12-20 00:16:10 +01:00
|
|
|
#endif
|
2004-06-01 15:27:40 +02:00
|
|
|
}
|
2003-12-20 00:16:10 +01:00
|
|
|
}
|
|
|
|
|
2004-08-03 12:32:21 +02:00
|
|
|
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
/*
|
|
|
|
DESCRIPTION
|
|
|
|
Destroy this prepared statement, cleaning up all used memory
|
|
|
|
and resources. This is called from ::deallocate() to
|
|
|
|
handle COM_STMT_CLOSE and DEALLOCATE PREPARE or when
|
|
|
|
THD ends and all prepared statements are freed.
|
|
|
|
*/
|
|
|
|
|
2003-12-20 00:16:10 +01:00
|
|
|
Prepared_statement::~Prepared_statement()
|
|
|
|
{
|
2005-07-29 04:06:35 +02:00
|
|
|
DBUG_ENTER("Prepared_statement::~Prepared_statement");
|
|
|
|
DBUG_PRINT("enter",("stmt: %p cursor: %p", this, cursor));
|
2005-09-22 00:11:21 +02:00
|
|
|
delete cursor;
|
2005-07-29 04:06:35 +02:00
|
|
|
/*
|
|
|
|
We have to call free on the items even if cleanup is called as some items,
|
|
|
|
like Item_param, don't free everything until free_items()
|
|
|
|
*/
|
|
|
|
free_items();
|
2004-08-24 18:17:11 +02:00
|
|
|
delete lex->result;
|
2005-07-29 04:06:35 +02:00
|
|
|
DBUG_VOID_RETURN;
|
2003-12-20 00:16:10 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2005-06-15 19:58:35 +02:00
|
|
|
Query_arena::Type Prepared_statement::type() const
|
2003-12-20 00:16:10 +01:00
|
|
|
{
|
|
|
|
return PREPARED_STATEMENT;
|
|
|
|
}
|
2005-07-14 13:27:24 +02:00
|
|
|
|
|
|
|
|
2005-09-22 00:11:21 +02:00
|
|
|
void Prepared_statement::cleanup_stmt()
|
2005-07-14 13:27:24 +02:00
|
|
|
{
|
2005-09-22 00:11:21 +02:00
|
|
|
DBUG_ENTER("Prepared_statement::cleanup_stmt");
|
2005-07-29 04:06:35 +02:00
|
|
|
DBUG_PRINT("enter",("stmt: %p", this));
|
|
|
|
|
2005-09-22 00:11:21 +02:00
|
|
|
/* The order is important */
|
|
|
|
lex->unit.cleanup();
|
|
|
|
cleanup_items(free_list);
|
|
|
|
thd->cleanup_after_query();
|
|
|
|
close_thread_tables(thd);
|
|
|
|
thd->rollback_item_tree_changes();
|
|
|
|
|
2005-07-29 04:06:35 +02:00
|
|
|
DBUG_VOID_RETURN;
|
2005-07-14 13:27:24 +02:00
|
|
|
}
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
bool Prepared_statement::set_name(LEX_STRING *name_arg)
|
|
|
|
{
|
|
|
|
name.length= name_arg->length;
|
|
|
|
name.str= memdup_root(mem_root, (char*) name_arg->str, name_arg->length);
|
|
|
|
return name.str == 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**************************************************************************
|
|
|
|
Common parts of mysql_[sql]_stmt_prepare, mysql_[sql]_stmt_execute.
|
|
|
|
Essentially, these functions do all the magic of preparing/executing
|
|
|
|
a statement, leaving network communication, input data handling and
|
|
|
|
global THD state management to the caller.
|
|
|
|
***************************************************************************/
|
|
|
|
|
|
|
|
/*
|
|
|
|
Parse statement text, validate the statement, and prepare it for execution.
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
Prepared_statement::prepare()
|
|
|
|
packet statement text
|
|
|
|
packet_len
|
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
You should not change global THD state in this function, if at all
|
|
|
|
possible: it may be called from any context, e.g. when executing
|
|
|
|
a COM_* command, and SQLCOM_* command, or a stored procedure.
|
|
|
|
|
|
|
|
NOTES
|
|
|
|
Precondition.
|
|
|
|
-------------
|
|
|
|
The caller must ensure that thd->change_list and thd->free_list
|
|
|
|
is empty: this function will not back them up but will free
|
|
|
|
in the end of its execution.
|
|
|
|
|
|
|
|
Postcondition.
|
|
|
|
--------------
|
|
|
|
thd->mem_root contains unused memory allocated during validation.
|
|
|
|
*/
|
|
|
|
|
|
|
|
bool Prepared_statement::prepare(const char *packet, uint packet_len)
|
|
|
|
{
|
2005-10-06 16:54:43 +02:00
|
|
|
bool error;
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
Statement stmt_backup;
|
|
|
|
Query_arena *old_stmt_arena;
|
|
|
|
DBUG_ENTER("Prepared_statement::prepare");
|
|
|
|
/*
|
|
|
|
If this is an SQLCOM_PREPARE, we also increase Com_prepare_sql.
|
|
|
|
However, it seems handy if com_stmt_prepare is increased always,
|
|
|
|
no matter what kind of prepare is processed.
|
|
|
|
*/
|
|
|
|
statistic_increment(thd->status_var.com_stmt_prepare, &LOCK_status);
|
|
|
|
|
|
|
|
/*
|
|
|
|
alloc_query() uses thd->memroot && thd->query, so we should call
|
|
|
|
both of backup_statement() and backup_query_arena() here.
|
|
|
|
*/
|
|
|
|
thd->set_n_backup_statement(this, &stmt_backup);
|
|
|
|
thd->set_n_backup_active_arena(this, &stmt_backup);
|
|
|
|
|
|
|
|
if (alloc_query(thd, packet, packet_len))
|
|
|
|
{
|
|
|
|
thd->restore_backup_statement(this, &stmt_backup);
|
|
|
|
thd->restore_active_arena(this, &stmt_backup);
|
|
|
|
DBUG_RETURN(TRUE);
|
|
|
|
}
|
|
|
|
|
|
|
|
old_stmt_arena= thd->stmt_arena;
|
|
|
|
thd->stmt_arena= this;
|
|
|
|
lex_start(thd, (uchar*) thd->query, thd->query_length);
|
|
|
|
lex->safe_to_cache_query= FALSE;
|
|
|
|
lex->stmt_prepare_mode= TRUE;
|
|
|
|
|
2006-03-10 01:44:08 +01:00
|
|
|
error= MYSQLparse((void *)thd) || thd->is_fatal_error ||
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
thd->net.report_error || init_param_array(this);
|
|
|
|
/*
|
|
|
|
While doing context analysis of the query (in check_prepared_statement)
|
|
|
|
we allocate a lot of additional memory: for open tables, JOINs, derived
|
|
|
|
tables, etc. Let's save a snapshot of current parse tree to the
|
|
|
|
statement and restore original THD. In cases when some tree
|
|
|
|
transformation can be reused on execute, we set again thd->mem_root from
|
|
|
|
stmt->mem_root (see setup_wild for one place where we do that).
|
|
|
|
*/
|
|
|
|
thd->restore_active_arena(this, &stmt_backup);
|
|
|
|
|
|
|
|
/*
|
|
|
|
If called from a stored procedure, ensure that we won't rollback
|
|
|
|
external changes when cleaning up after validation.
|
|
|
|
*/
|
|
|
|
DBUG_ASSERT(thd->change_list.is_empty());
|
|
|
|
/*
|
|
|
|
If the free_list is not empty, we'll wrongly free some externally
|
|
|
|
allocated items when cleaning up after validation of the prepared
|
|
|
|
statement.
|
|
|
|
*/
|
|
|
|
DBUG_ASSERT(thd->free_list == NULL);
|
|
|
|
|
2005-10-06 16:54:43 +02:00
|
|
|
if (error == 0)
|
|
|
|
error= check_prepared_statement(this, name.str != 0);
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
|
2005-10-08 02:37:23 +02:00
|
|
|
if (error && lex->sphead)
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
{
|
2005-09-22 00:11:21 +02:00
|
|
|
delete lex->sphead;
|
|
|
|
lex->sphead= NULL;
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
}
|
|
|
|
lex_end(lex);
|
2005-09-22 00:11:21 +02:00
|
|
|
cleanup_stmt();
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
thd->restore_backup_statement(this, &stmt_backup);
|
|
|
|
thd->stmt_arena= old_stmt_arena;
|
|
|
|
|
2005-10-06 16:54:43 +02:00
|
|
|
if (error == 0)
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
{
|
|
|
|
setup_set_params();
|
|
|
|
init_stmt_after_parse(lex);
|
|
|
|
state= Query_arena::PREPARED;
|
2005-10-06 16:54:43 +02:00
|
|
|
flags&= ~ (uint) IS_IN_USE;
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
}
|
2005-10-06 16:54:43 +02:00
|
|
|
DBUG_RETURN(error);
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
Execute a prepared statement.
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
Prepared_statement::execute()
|
|
|
|
expanded_query A query for binlogging which has all parameter
|
|
|
|
markers ('?') replaced with their actual values.
|
|
|
|
open_cursor True if an attempt to open a cursor should be made.
|
|
|
|
Currenlty used only in the binary protocol.
|
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
You should not change global THD state in this function, if at all
|
|
|
|
possible: it may be called from any context, e.g. when executing
|
|
|
|
a COM_* command, and SQLCOM_* command, or a stored procedure.
|
|
|
|
|
|
|
|
NOTES
|
|
|
|
Preconditions, postconditions.
|
|
|
|
------------------------------
|
|
|
|
See the comment for Prepared_statement::prepare().
|
2005-10-06 16:54:43 +02:00
|
|
|
|
|
|
|
RETURN
|
|
|
|
FALSE ok
|
|
|
|
TRUE Error
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
*/
|
|
|
|
|
|
|
|
bool Prepared_statement::execute(String *expanded_query, bool open_cursor)
|
|
|
|
{
|
|
|
|
Statement stmt_backup;
|
|
|
|
Query_arena *old_stmt_arena;
|
|
|
|
Item *old_free_list;
|
2005-10-06 16:54:43 +02:00
|
|
|
bool error= TRUE;
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
|
|
|
|
statistic_increment(thd->status_var.com_stmt_execute, &LOCK_status);
|
|
|
|
|
|
|
|
/* Check if we got an error when sending long data */
|
|
|
|
if (state == Query_arena::ERROR)
|
|
|
|
{
|
|
|
|
my_message(last_errno, last_error, MYF(0));
|
2005-09-22 00:11:21 +02:00
|
|
|
return TRUE;
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
}
|
2005-10-06 16:54:43 +02:00
|
|
|
if (flags & (uint) IS_IN_USE)
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
{
|
|
|
|
my_error(ER_PS_NO_RECURSION, MYF(0));
|
2005-09-22 00:11:21 +02:00
|
|
|
return TRUE;
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
}
|
2005-09-22 00:11:21 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
For SHOW VARIABLES lex->result is NULL, as it's a non-SELECT
|
|
|
|
command. For such queries we don't return an error and don't
|
|
|
|
open a cursor -- the client library will recognize this case and
|
|
|
|
materialize the result set.
|
|
|
|
For SELECT statements lex->result is created in
|
|
|
|
check_prepared_statement. lex->result->simple_select() is FALSE
|
|
|
|
in INSERT ... SELECT and similar commands.
|
|
|
|
*/
|
|
|
|
|
|
|
|
if (open_cursor && lex->result && !lex->result->simple_select())
|
|
|
|
{
|
|
|
|
DBUG_PRINT("info",("Cursor asked for not SELECT stmt"));
|
|
|
|
my_error(ER_SP_BAD_CURSOR_QUERY, MYF(0));
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
/* In case the command has a call to SP which re-uses this statement name */
|
|
|
|
flags|= IS_IN_USE;
|
|
|
|
|
2005-09-22 00:11:21 +02:00
|
|
|
close_cursor();
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
If the free_list is not empty, we'll wrongly free some externally
|
|
|
|
allocated items when cleaning up after execution of this statement.
|
|
|
|
*/
|
|
|
|
DBUG_ASSERT(thd->change_list.is_empty());
|
|
|
|
DBUG_ASSERT(thd->free_list == NULL);
|
|
|
|
thd->set_n_backup_statement(this, &stmt_backup);
|
|
|
|
if (expanded_query->length() &&
|
|
|
|
alloc_query(thd, (char*) expanded_query->ptr(),
|
|
|
|
expanded_query->length()+1))
|
|
|
|
{
|
|
|
|
my_error(ER_OUTOFMEMORY, 0, expanded_query->length());
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
/*
|
|
|
|
Expanded query is needed for slow logging, so we want thd->query
|
|
|
|
to point at it even after we restore from backup. This is ok, as
|
|
|
|
expanded query was allocated in thd->mem_root.
|
|
|
|
*/
|
|
|
|
stmt_backup.query= thd->query;
|
|
|
|
stmt_backup.query_length= thd->query_length;
|
|
|
|
|
|
|
|
/*
|
|
|
|
At first execution of prepared statement we may perform logical
|
|
|
|
transformations of the query tree. Such changes should be performed
|
|
|
|
on the parse tree of current prepared statement and new items should
|
|
|
|
be allocated in its memory root. Set the appropriate pointer in THD
|
|
|
|
to the arena of the statement.
|
|
|
|
*/
|
|
|
|
old_stmt_arena= thd->stmt_arena;
|
|
|
|
thd->stmt_arena= this;
|
|
|
|
reinit_stmt_before_use(thd, lex);
|
|
|
|
|
|
|
|
thd->protocol= protocol; /* activate stmt protocol */
|
2005-10-08 02:37:23 +02:00
|
|
|
error= (open_cursor ?
|
|
|
|
mysql_open_cursor(thd, (uint) ALWAYS_MATERIALIZED_CURSOR,
|
|
|
|
&result, &cursor) :
|
|
|
|
mysql_execute_command(thd));
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
thd->protocol= &thd->protocol_simple; /* use normal protocol */
|
|
|
|
|
2005-09-22 00:11:21 +02:00
|
|
|
/* Assert that if an error, no cursor is open */
|
2005-10-11 23:58:22 +02:00
|
|
|
DBUG_ASSERT(! (error && cursor));
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
|
2005-09-22 00:11:21 +02:00
|
|
|
if (! cursor)
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
{
|
2005-09-22 00:11:21 +02:00
|
|
|
cleanup_stmt();
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
reset_stmt_params(this);
|
|
|
|
}
|
|
|
|
|
|
|
|
thd->set_statement(&stmt_backup);
|
|
|
|
thd->stmt_arena= old_stmt_arena;
|
|
|
|
|
|
|
|
if (state == Query_arena::PREPARED)
|
|
|
|
state= Query_arena::EXECUTED;
|
|
|
|
|
|
|
|
error:
|
2005-10-06 16:54:43 +02:00
|
|
|
flags&= ~ (uint) IS_IN_USE;
|
|
|
|
return error;
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* Common part of DEALLOCATE PREPARE and mysql_stmt_close */
|
|
|
|
|
|
|
|
bool Prepared_statement::deallocate()
|
|
|
|
{
|
|
|
|
/* We account deallocate in the same manner as mysql_stmt_close */
|
|
|
|
statistic_increment(thd->status_var.com_stmt_close, &LOCK_status);
|
2005-10-06 16:54:43 +02:00
|
|
|
if (flags & (uint) IS_IN_USE)
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
{
|
|
|
|
my_error(ER_PS_NO_RECURSION, MYF(0));
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
/* Statement map calls delete stmt on erase */
|
|
|
|
thd->stmt_map.erase(this);
|
|
|
|
return FALSE;
|
|
|
|
}
|