2008-11-10 21:21:49 +01:00
|
|
|
/* Copyright 2000-2008 MySQL AB, 2008 Sun Microsystems, Inc.
|
2001-12-06 13:10:51 +01:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
This program is free software; you can redistribute it and/or modify
|
|
|
|
it under the terms of the GNU General Public License as published by
|
2006-12-23 20:17:15 +01:00
|
|
|
the Free Software Foundation; version 2 of the License.
|
2001-12-06 13:10:51 +01:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
This program is distributed in the hope that it will be useful,
|
|
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
GNU General Public License for more details.
|
2001-12-06 13:10:51 +01:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
You should have received a copy of the GNU General Public License
|
|
|
|
along with this program; if not, write to the Free Software
|
|
|
|
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */
|
|
|
|
|
|
|
|
|
|
|
|
/* A lexical scanner on a temporary buffer with a yacc interface */
|
|
|
|
|
2006-03-09 19:09:52 +01:00
|
|
|
#define MYSQL_LEX 1
|
2010-03-31 16:05:33 +02:00
|
|
|
#include "sql_priv.h"
|
|
|
|
#include "unireg.h" // REQUIRED: for other includes
|
|
|
|
#include "sql_class.h" // sql_lex.h: SQLCOM_END
|
|
|
|
#include "sql_lex.h"
|
|
|
|
#include "sql_parse.h" // add_to_list
|
2000-07-31 21:29:14 +02:00
|
|
|
#include "item_create.h"
|
|
|
|
#include <m_ctype.h>
|
|
|
|
#include <hash.h>
|
2003-02-26 19:22:29 +01:00
|
|
|
#include "sp.h"
|
|
|
|
#include "sp_head.h"
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2009-11-02 17:31:00 +01:00
|
|
|
static int lex_one_token(void *arg, void *yythd);
|
|
|
|
|
2004-09-07 14:29:46 +02:00
|
|
|
/*
|
|
|
|
We are using pointer to this variable for distinguishing between assignment
|
|
|
|
to NEW row field (when parsing trigger definition) and structured variable.
|
|
|
|
*/
|
2005-11-06 01:36:40 +01:00
|
|
|
|
|
|
|
sys_var *trg_new_row_fake_var= (sys_var*) 0x01;
|
2004-08-10 10:42:31 +02:00
|
|
|
|
2009-10-09 16:29:51 +02:00
|
|
|
/**
|
|
|
|
LEX_STRING constant for null-string to be used in parser and other places.
|
|
|
|
*/
|
|
|
|
const LEX_STRING null_lex_str= {NULL, 0};
|
Backport of revno 2630.28.10, 2630.28.31, 2630.28.26, 2630.33.1,
2630.39.1, 2630.28.29, 2630.34.3, 2630.34.2, 2630.34.1, 2630.29.29,
2630.29.28, 2630.31.1, 2630.28.13, 2630.28.10, 2617.23.14 and
some other minor revisions.
This patch implements:
WL#4264 "Backup: Stabilize Service Interface" -- all the
server prerequisites except si_objects.{h,cc} themselves (they can
be just copied over, when needed).
WL#4435: Support OUT-parameters in prepared statements.
(and all issues in the initial patches for these two
tasks, that were discovered in pushbuild and during testing).
Bug#39519: mysql_stmt_close() should flush all data
associated with the statement.
After execution of a prepared statement, send OUT parameters of the invoked
stored procedure, if any, to the client.
When using the binary protocol, send the parameters in an additional result
set over the wire. When using the text protocol, assign out parameters to
the user variables from the CALL(@var1, @var2, ...) specification.
The following refactoring has been made:
- Protocol::send_fields() was renamed to Protocol::send_result_set_metadata();
- A new Protocol::send_result_set_row() was introduced to incapsulate
common functionality for sending row data.
- Signature of Protocol::prepare_for_send() was changed: this operation
does not need a list of items, the number of items is fully sufficient.
The following backward incompatible changes have been made:
- CLIENT_MULTI_RESULTS is now enabled by default in the client;
- CLIENT_PS_MULTI_RESUTLS is now enabled by default in the client.
2009-10-21 22:02:06 +02:00
|
|
|
const LEX_STRING empty_lex_str= { (char*) "", 0 };
|
2009-10-14 18:32:08 +02:00
|
|
|
/**
|
|
|
|
@note The order of the elements of this array must correspond to
|
|
|
|
the order of elements in enum_binlog_stmt_unsafe.
|
|
|
|
*/
|
|
|
|
const int
|
|
|
|
Query_tables_list::binlog_stmt_unsafe_errcode[BINLOG_STMT_UNSAFE_COUNT] =
|
|
|
|
{
|
|
|
|
ER_BINLOG_UNSAFE_LIMIT,
|
|
|
|
ER_BINLOG_UNSAFE_INSERT_DELAYED,
|
|
|
|
ER_BINLOG_UNSAFE_SYSTEM_TABLE,
|
2010-01-29 14:55:35 +01:00
|
|
|
ER_BINLOG_UNSAFE_AUTOINC_COLUMNS,
|
2009-10-14 18:32:08 +02:00
|
|
|
ER_BINLOG_UNSAFE_UDF,
|
|
|
|
ER_BINLOG_UNSAFE_SYSTEM_VARIABLE,
|
2009-11-03 20:02:56 +01:00
|
|
|
ER_BINLOG_UNSAFE_SYSTEM_FUNCTION,
|
2010-02-22 04:25:33 +01:00
|
|
|
ER_BINLOG_UNSAFE_NONTRANS_AFTER_TRANS,
|
BUG#51291 Unfortunate effect around variable binlog_direct_non_transactional_updates
BUG#46364 introduced the flag binlog_direct_non_transactional_updates which
would make N-changes to be written to the binary log upon committing the
statement when "ON". On the other hand, when "OFF" the option was supposed
to mimic the behavior in 5.1. However, the implementation was not mimicking
the behavior correctly and the following bugs popped up:
Case #1: N-changes executed within a transaction would go into
the S-cache. When later in the same transaction a
T-change occurs, N-changes following it were written
to the T-cache instead of the S-cache. In some cases,
this raises problems. For example, a
Table_map_log_event being written initially into the
S-cache, together with the initial N-changes, would be
absent from the T-cache. This would log N-changes
orphaned from a Table_map_log_event (thence discarded
at the slave). (MIXED and ROW)
Case #2: When rolling back a transaction, the N-changes that
might be in the T-cache were disregarded and
truncated along with the T-changes. (MIXED and ROW)
Case #3: When a MIXED statement (TN) is ahead of any other
T-changes in the transaction and it fails, it is kept
in the T-cache until the transaction ends. This is
not the case in 5.1 or Betony (5.5.2). In these, the
failed TN statement would be written to the binlog at
the same instant it had failed and not deferred until
transaction end. (SBR)
To fix these problems, we have decided to do what follows:
For Case #1 and #2, we circumvent them:
1. by not letting binlog_direct_non_transactional_updates
affect MIXED and RBR. These modes will keep the behavior
provided by WL#2687. Although this will make Celosia to
behave differently from 5.1, an execution will be always
safe under such modes in the sense that slaves will never
go out sync. In 5.1, using either MIXED or ROW while
mixing N-statements and T-statements was not safe.
For Case #3, we don't actually fix it. We:
1. keep it and make all MIXED statements whether they end
up failing or not or whether they are up front in the
transaction or after some transactional change to always
be stored in the T-cache. This means that it is written
to the binary log on transaction commit/rollback only.
2. We make the warning message even more specific about the
MIXED statement and SBR.
2010-03-31 15:22:47 +02:00
|
|
|
ER_BINLOG_UNSAFE_MULTIPLE_ENGINES_AND_SELF_LOGGING_ENGINE,
|
|
|
|
ER_BINLOG_UNSAFE_MIXED_STATEMENT,
|
2009-10-14 18:32:08 +02:00
|
|
|
};
|
|
|
|
|
2009-10-09 16:29:51 +02:00
|
|
|
|
2003-11-03 13:01:59 +01:00
|
|
|
/* Longest standard keyword name */
|
2009-10-09 16:29:51 +02:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
#define TOCK_NAME_LENGTH 24
|
|
|
|
|
2003-11-03 13:01:59 +01:00
|
|
|
/*
|
|
|
|
The following data is based on the latin1 character set, and is only
|
2000-07-31 21:29:14 +02:00
|
|
|
used when comparing keywords
|
|
|
|
*/
|
|
|
|
|
2005-05-18 18:00:21 +02:00
|
|
|
static uchar to_upper_lex[]=
|
|
|
|
{
|
2000-07-31 21:29:14 +02:00
|
|
|
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
|
|
|
|
16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31,
|
|
|
|
32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47,
|
|
|
|
48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63,
|
|
|
|
64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79,
|
|
|
|
80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95,
|
|
|
|
96, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79,
|
|
|
|
80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90,123,124,125,126,127,
|
|
|
|
128,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,
|
|
|
|
144,145,146,147,148,149,150,151,152,153,154,155,156,157,158,159,
|
|
|
|
160,161,162,163,164,165,166,167,168,169,170,171,172,173,174,175,
|
|
|
|
176,177,178,179,180,181,182,183,184,185,186,187,188,189,190,191,
|
|
|
|
192,193,194,195,196,197,198,199,200,201,202,203,204,205,206,207,
|
|
|
|
208,209,210,211,212,213,214,215,216,217,218,219,220,221,222,223,
|
|
|
|
192,193,194,195,196,197,198,199,200,201,202,203,204,205,206,207,
|
|
|
|
208,209,210,211,212,213,214,247,216,217,218,219,220,221,222,255
|
|
|
|
};
|
|
|
|
|
2007-03-05 18:08:41 +01:00
|
|
|
/*
|
|
|
|
Names of the index hints (for error messages). Keep in sync with
|
|
|
|
index_hint_type
|
|
|
|
*/
|
|
|
|
|
|
|
|
const char * index_hint_type_name[] =
|
|
|
|
{
|
|
|
|
"IGNORE INDEX",
|
|
|
|
"USE INDEX",
|
|
|
|
"FORCE INDEX"
|
|
|
|
};
|
2003-11-03 13:01:59 +01:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
inline int lex_casecmp(const char *s, const char *t, uint len)
|
|
|
|
{
|
|
|
|
while (len-- != 0 &&
|
|
|
|
to_upper_lex[(uchar) *s++] == to_upper_lex[(uchar) *t++]) ;
|
|
|
|
return (int) len+1;
|
|
|
|
}
|
|
|
|
|
2006-04-13 09:57:51 +02:00
|
|
|
#include <lex_hash.h>
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
void lex_init(void)
|
|
|
|
{
|
|
|
|
uint i;
|
|
|
|
DBUG_ENTER("lex_init");
|
|
|
|
for (i=0 ; i < array_elements(symbols) ; i++)
|
|
|
|
symbols[i].length=(uchar) strlen(symbols[i].name);
|
|
|
|
for (i=0 ; i < array_elements(sql_functions) ; i++)
|
|
|
|
sql_functions[i].length=(uchar) strlen(sql_functions[i].name);
|
|
|
|
|
|
|
|
DBUG_VOID_RETURN;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
void lex_free(void)
|
|
|
|
{ // Call this when daemon ends
|
|
|
|
DBUG_ENTER("lex_free");
|
|
|
|
DBUG_VOID_RETURN;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2007-02-04 14:49:24 +01:00
|
|
|
void
|
|
|
|
st_parsing_options::reset()
|
|
|
|
{
|
|
|
|
allows_variable= TRUE;
|
|
|
|
allows_select_into= TRUE;
|
|
|
|
allows_select_procedure= TRUE;
|
|
|
|
allows_derived= TRUE;
|
|
|
|
}
|
|
|
|
|
2010-05-14 20:11:25 +02:00
|
|
|
|
|
|
|
/**
|
|
|
|
Perform initialization of Lex_input_stream instance.
|
|
|
|
|
|
|
|
Basically, a buffer for pre-processed query. This buffer should be large
|
|
|
|
enough to keep multi-statement query. The allocation is done once in the
|
|
|
|
Lex_input_stream constructor in order to prevent memory pollution when
|
|
|
|
the server is processing large multi-statement queries.
|
|
|
|
|
|
|
|
@todo Check return value of THD::alloc().
|
|
|
|
*/
|
|
|
|
|
2007-04-26 05:38:12 +02:00
|
|
|
Lex_input_stream::Lex_input_stream(THD *thd,
|
|
|
|
const char* buffer,
|
|
|
|
unsigned int length)
|
2010-05-14 20:11:25 +02:00
|
|
|
:m_thd(thd)
|
2007-04-26 05:38:12 +02:00
|
|
|
{
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
m_cpp_buf= (char*) thd->alloc(length + 1);
|
2010-05-14 20:11:25 +02:00
|
|
|
reset(buffer, length);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
Prepare Lex_input_stream instance state for use for handling next SQL statement.
|
|
|
|
|
|
|
|
It should be called between two statements in a multi-statement query.
|
|
|
|
The operation resets the input stream to the beginning-of-parse state,
|
|
|
|
but does not reallocate m_cpp_buf.
|
|
|
|
*/
|
|
|
|
|
|
|
|
void
|
|
|
|
Lex_input_stream::reset(const char *buffer, unsigned int length)
|
|
|
|
{
|
|
|
|
yylineno= 1;
|
|
|
|
yytoklen= 0;
|
|
|
|
yylval= NULL;
|
|
|
|
lookahead_token= -1;
|
|
|
|
lookahead_yylval= NULL;
|
|
|
|
m_ptr= buffer;
|
|
|
|
m_tok_start= NULL;
|
|
|
|
m_tok_end= NULL;
|
|
|
|
m_end_of_query= buffer + length;
|
|
|
|
m_tok_start_prev= NULL;
|
|
|
|
m_buf= buffer;
|
|
|
|
m_buf_length= length;
|
|
|
|
m_echo= TRUE;
|
|
|
|
m_cpp_tok_start= NULL;
|
|
|
|
m_cpp_tok_start_prev= NULL;
|
|
|
|
m_cpp_tok_end= NULL;
|
|
|
|
m_body_utf8= NULL;
|
|
|
|
m_cpp_utf8_processed_ptr= NULL;
|
|
|
|
next_state= MY_LEX_START;
|
|
|
|
found_semicolon= NULL;
|
|
|
|
ignore_space= test(m_thd->variables.sql_mode & MODE_IGNORE_SPACE);
|
|
|
|
stmt_prepare_mode= FALSE;
|
|
|
|
multi_statements= TRUE;
|
|
|
|
in_comment=NO_COMMENT;
|
|
|
|
m_underscore_cs= NULL;
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
m_cpp_ptr= m_cpp_buf;
|
2007-04-26 05:38:12 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
Lex_input_stream::~Lex_input_stream()
|
|
|
|
{}
|
|
|
|
|
Patch for the following bugs:
- BUG#11986: Stored routines and triggers can fail if the code
has a non-ascii symbol
- BUG#16291: mysqldump corrupts string-constants with non-ascii-chars
- BUG#19443: INFORMATION_SCHEMA does not support charsets properly
- BUG#21249: Character set of SP-var can be ignored
- BUG#25212: Character set of string constant is ignored (stored routines)
- BUG#25221: Character set of string constant is ignored (triggers)
There were a few general problems that caused these bugs:
1. Character set information of the original (definition) query for views,
triggers, stored routines and events was lost.
2. mysqldump output query in client character set, which can be
inappropriate to encode definition-query.
3. INFORMATION_SCHEMA used strings with mixed encodings to display object
definition;
1. No query-definition-character set.
In order to compile query into execution code, some extra data (such as
environment variables or the database character set) is used. The problem
here was that this context was not preserved. So, on the next load it can
differ from the original one, thus the result will be different.
The context contains the following data:
- client character set;
- connection collation (character set and collation);
- collation of the owner database;
The fix is to store this context and use it each time we parse (compile)
and execute the object (stored routine, trigger, ...).
2. Wrong mysqldump-output.
The original query can contain several encodings (by means of character set
introducers). The problem here was that we tried to convert original query
to the mysqldump-client character set.
Moreover, we stored queries in different character sets for different
objects (views, for one, used UTF8, triggers used original character set).
The solution is
- to store definition queries in the original character set;
- to change SHOW CREATE statement to output definition query in the
binary character set (i.e. without any conversion);
- introduce SHOW CREATE TRIGGER statement;
- to dump special statements to switch the context to the original one
before dumping and restore it afterwards.
Note, in order to preserve the database collation at the creation time,
additional ALTER DATABASE might be used (to temporary switch the database
collation back to the original value). In this case, ALTER DATABASE
privilege will be required. This is a backward-incompatible change.
3. INFORMATION_SCHEMA showed non-UTF8 strings
The fix is to generate UTF8-query during the parsing, store it in the object
and show it in the INFORMATION_SCHEMA.
Basically, the idea is to create a copy of the original query convert it to
UTF8. Character set introducers are removed and all text literals are
converted to UTF8.
This UTF8 query is intended to provide user-readable output. It must not be
used to recreate the object. Specialized SHOW CREATE statements should be
used for this.
The reason for this limitation is the following: the original query can
contain symbols from several character sets (by means of character set
introducers).
Example:
- original query:
CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1;
- UTF8 query (for INFORMATION_SCHEMA):
CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 19:34:54 +02:00
|
|
|
/**
|
|
|
|
The operation is called from the parser in order to
|
|
|
|
1) designate the intention to have utf8 body;
|
|
|
|
1) Indicate to the lexer that we will need a utf8 representation of this
|
|
|
|
statement;
|
|
|
|
2) Determine the beginning of the body.
|
|
|
|
|
|
|
|
@param thd Thread context.
|
|
|
|
@param begin_ptr Pointer to the start of the body in the pre-processed
|
|
|
|
buffer.
|
|
|
|
*/
|
|
|
|
|
|
|
|
void Lex_input_stream::body_utf8_start(THD *thd, const char *begin_ptr)
|
|
|
|
{
|
|
|
|
DBUG_ASSERT(begin_ptr);
|
|
|
|
DBUG_ASSERT(m_cpp_buf <= begin_ptr && begin_ptr <= m_cpp_buf + m_buf_length);
|
|
|
|
|
|
|
|
uint body_utf8_length=
|
|
|
|
(m_buf_length / thd->variables.character_set_client->mbminlen) *
|
|
|
|
my_charset_utf8_bin.mbmaxlen;
|
|
|
|
|
|
|
|
m_body_utf8= (char *) thd->alloc(body_utf8_length + 1);
|
|
|
|
m_body_utf8_ptr= m_body_utf8;
|
|
|
|
*m_body_utf8_ptr= 0;
|
|
|
|
|
|
|
|
m_cpp_utf8_processed_ptr= begin_ptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2007-08-15 15:43:08 +02:00
|
|
|
@brief The operation appends unprocessed part of pre-processed buffer till
|
Patch for the following bugs:
- BUG#11986: Stored routines and triggers can fail if the code
has a non-ascii symbol
- BUG#16291: mysqldump corrupts string-constants with non-ascii-chars
- BUG#19443: INFORMATION_SCHEMA does not support charsets properly
- BUG#21249: Character set of SP-var can be ignored
- BUG#25212: Character set of string constant is ignored (stored routines)
- BUG#25221: Character set of string constant is ignored (triggers)
There were a few general problems that caused these bugs:
1. Character set information of the original (definition) query for views,
triggers, stored routines and events was lost.
2. mysqldump output query in client character set, which can be
inappropriate to encode definition-query.
3. INFORMATION_SCHEMA used strings with mixed encodings to display object
definition;
1. No query-definition-character set.
In order to compile query into execution code, some extra data (such as
environment variables or the database character set) is used. The problem
here was that this context was not preserved. So, on the next load it can
differ from the original one, thus the result will be different.
The context contains the following data:
- client character set;
- connection collation (character set and collation);
- collation of the owner database;
The fix is to store this context and use it each time we parse (compile)
and execute the object (stored routine, trigger, ...).
2. Wrong mysqldump-output.
The original query can contain several encodings (by means of character set
introducers). The problem here was that we tried to convert original query
to the mysqldump-client character set.
Moreover, we stored queries in different character sets for different
objects (views, for one, used UTF8, triggers used original character set).
The solution is
- to store definition queries in the original character set;
- to change SHOW CREATE statement to output definition query in the
binary character set (i.e. without any conversion);
- introduce SHOW CREATE TRIGGER statement;
- to dump special statements to switch the context to the original one
before dumping and restore it afterwards.
Note, in order to preserve the database collation at the creation time,
additional ALTER DATABASE might be used (to temporary switch the database
collation back to the original value). In this case, ALTER DATABASE
privilege will be required. This is a backward-incompatible change.
3. INFORMATION_SCHEMA showed non-UTF8 strings
The fix is to generate UTF8-query during the parsing, store it in the object
and show it in the INFORMATION_SCHEMA.
Basically, the idea is to create a copy of the original query convert it to
UTF8. Character set introducers are removed and all text literals are
converted to UTF8.
This UTF8 query is intended to provide user-readable output. It must not be
used to recreate the object. Specialized SHOW CREATE statements should be
used for this.
The reason for this limitation is the following: the original query can
contain symbols from several character sets (by means of character set
introducers).
Example:
- original query:
CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1;
- UTF8 query (for INFORMATION_SCHEMA):
CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 19:34:54 +02:00
|
|
|
the given pointer (ptr) and sets m_cpp_utf8_processed_ptr to end_ptr.
|
|
|
|
|
|
|
|
The idea is that some tokens in the pre-processed buffer (like character
|
|
|
|
set introducers) should be skipped.
|
|
|
|
|
|
|
|
Example:
|
|
|
|
CPP buffer: SELECT 'str1', _latin1 'str2';
|
|
|
|
m_cpp_utf8_processed_ptr -- points at the "SELECT ...";
|
|
|
|
In order to skip "_latin1", the following call should be made:
|
|
|
|
body_utf8_append(<pointer to "_latin1 ...">, <pointer to " 'str2'...">)
|
|
|
|
|
|
|
|
@param ptr Pointer in the pre-processed buffer, which specifies the
|
|
|
|
end of the chunk, which should be appended to the utf8
|
|
|
|
body.
|
|
|
|
@param end_ptr Pointer in the pre-processed buffer, to which
|
|
|
|
m_cpp_utf8_processed_ptr will be set in the end of the
|
|
|
|
operation.
|
|
|
|
*/
|
|
|
|
|
|
|
|
void Lex_input_stream::body_utf8_append(const char *ptr,
|
|
|
|
const char *end_ptr)
|
|
|
|
{
|
|
|
|
DBUG_ASSERT(m_cpp_buf <= ptr && ptr <= m_cpp_buf + m_buf_length);
|
|
|
|
DBUG_ASSERT(m_cpp_buf <= end_ptr && end_ptr <= m_cpp_buf + m_buf_length);
|
|
|
|
|
|
|
|
if (!m_body_utf8)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (m_cpp_utf8_processed_ptr >= ptr)
|
|
|
|
return;
|
|
|
|
|
|
|
|
int bytes_to_copy= ptr - m_cpp_utf8_processed_ptr;
|
|
|
|
|
|
|
|
memcpy(m_body_utf8_ptr, m_cpp_utf8_processed_ptr, bytes_to_copy);
|
|
|
|
m_body_utf8_ptr += bytes_to_copy;
|
|
|
|
*m_body_utf8_ptr= 0;
|
|
|
|
|
|
|
|
m_cpp_utf8_processed_ptr= end_ptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
The operation appends unprocessed part of the pre-processed buffer till
|
|
|
|
the given pointer (ptr) and sets m_cpp_utf8_processed_ptr to ptr.
|
|
|
|
|
|
|
|
@param ptr Pointer in the pre-processed buffer, which specifies the end
|
|
|
|
of the chunk, which should be appended to the utf8 body.
|
|
|
|
*/
|
|
|
|
|
|
|
|
void Lex_input_stream::body_utf8_append(const char *ptr)
|
|
|
|
{
|
|
|
|
body_utf8_append(ptr, ptr);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
The operation converts the specified text literal to the utf8 and appends
|
|
|
|
the result to the utf8-body.
|
|
|
|
|
|
|
|
@param thd Thread context.
|
|
|
|
@param txt Text literal.
|
|
|
|
@param txt_cs Character set of the text literal.
|
|
|
|
@param end_ptr Pointer in the pre-processed buffer, to which
|
|
|
|
m_cpp_utf8_processed_ptr will be set in the end of the
|
|
|
|
operation.
|
|
|
|
*/
|
|
|
|
|
|
|
|
void Lex_input_stream::body_utf8_append_literal(THD *thd,
|
|
|
|
const LEX_STRING *txt,
|
|
|
|
CHARSET_INFO *txt_cs,
|
|
|
|
const char *end_ptr)
|
|
|
|
{
|
|
|
|
if (!m_cpp_utf8_processed_ptr)
|
|
|
|
return;
|
|
|
|
|
|
|
|
LEX_STRING utf_txt;
|
|
|
|
|
2007-06-29 15:59:19 +02:00
|
|
|
if (!my_charset_same(txt_cs, &my_charset_utf8_general_ci))
|
Patch for the following bugs:
- BUG#11986: Stored routines and triggers can fail if the code
has a non-ascii symbol
- BUG#16291: mysqldump corrupts string-constants with non-ascii-chars
- BUG#19443: INFORMATION_SCHEMA does not support charsets properly
- BUG#21249: Character set of SP-var can be ignored
- BUG#25212: Character set of string constant is ignored (stored routines)
- BUG#25221: Character set of string constant is ignored (triggers)
There were a few general problems that caused these bugs:
1. Character set information of the original (definition) query for views,
triggers, stored routines and events was lost.
2. mysqldump output query in client character set, which can be
inappropriate to encode definition-query.
3. INFORMATION_SCHEMA used strings with mixed encodings to display object
definition;
1. No query-definition-character set.
In order to compile query into execution code, some extra data (such as
environment variables or the database character set) is used. The problem
here was that this context was not preserved. So, on the next load it can
differ from the original one, thus the result will be different.
The context contains the following data:
- client character set;
- connection collation (character set and collation);
- collation of the owner database;
The fix is to store this context and use it each time we parse (compile)
and execute the object (stored routine, trigger, ...).
2. Wrong mysqldump-output.
The original query can contain several encodings (by means of character set
introducers). The problem here was that we tried to convert original query
to the mysqldump-client character set.
Moreover, we stored queries in different character sets for different
objects (views, for one, used UTF8, triggers used original character set).
The solution is
- to store definition queries in the original character set;
- to change SHOW CREATE statement to output definition query in the
binary character set (i.e. without any conversion);
- introduce SHOW CREATE TRIGGER statement;
- to dump special statements to switch the context to the original one
before dumping and restore it afterwards.
Note, in order to preserve the database collation at the creation time,
additional ALTER DATABASE might be used (to temporary switch the database
collation back to the original value). In this case, ALTER DATABASE
privilege will be required. This is a backward-incompatible change.
3. INFORMATION_SCHEMA showed non-UTF8 strings
The fix is to generate UTF8-query during the parsing, store it in the object
and show it in the INFORMATION_SCHEMA.
Basically, the idea is to create a copy of the original query convert it to
UTF8. Character set introducers are removed and all text literals are
converted to UTF8.
This UTF8 query is intended to provide user-readable output. It must not be
used to recreate the object. Specialized SHOW CREATE statements should be
used for this.
The reason for this limitation is the following: the original query can
contain symbols from several character sets (by means of character set
introducers).
Example:
- original query:
CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1;
- UTF8 query (for INFORMATION_SCHEMA):
CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 19:34:54 +02:00
|
|
|
{
|
|
|
|
thd->convert_string(&utf_txt,
|
|
|
|
&my_charset_utf8_general_ci,
|
2009-02-13 17:41:47 +01:00
|
|
|
txt->str, (uint) txt->length,
|
Patch for the following bugs:
- BUG#11986: Stored routines and triggers can fail if the code
has a non-ascii symbol
- BUG#16291: mysqldump corrupts string-constants with non-ascii-chars
- BUG#19443: INFORMATION_SCHEMA does not support charsets properly
- BUG#21249: Character set of SP-var can be ignored
- BUG#25212: Character set of string constant is ignored (stored routines)
- BUG#25221: Character set of string constant is ignored (triggers)
There were a few general problems that caused these bugs:
1. Character set information of the original (definition) query for views,
triggers, stored routines and events was lost.
2. mysqldump output query in client character set, which can be
inappropriate to encode definition-query.
3. INFORMATION_SCHEMA used strings with mixed encodings to display object
definition;
1. No query-definition-character set.
In order to compile query into execution code, some extra data (such as
environment variables or the database character set) is used. The problem
here was that this context was not preserved. So, on the next load it can
differ from the original one, thus the result will be different.
The context contains the following data:
- client character set;
- connection collation (character set and collation);
- collation of the owner database;
The fix is to store this context and use it each time we parse (compile)
and execute the object (stored routine, trigger, ...).
2. Wrong mysqldump-output.
The original query can contain several encodings (by means of character set
introducers). The problem here was that we tried to convert original query
to the mysqldump-client character set.
Moreover, we stored queries in different character sets for different
objects (views, for one, used UTF8, triggers used original character set).
The solution is
- to store definition queries in the original character set;
- to change SHOW CREATE statement to output definition query in the
binary character set (i.e. without any conversion);
- introduce SHOW CREATE TRIGGER statement;
- to dump special statements to switch the context to the original one
before dumping and restore it afterwards.
Note, in order to preserve the database collation at the creation time,
additional ALTER DATABASE might be used (to temporary switch the database
collation back to the original value). In this case, ALTER DATABASE
privilege will be required. This is a backward-incompatible change.
3. INFORMATION_SCHEMA showed non-UTF8 strings
The fix is to generate UTF8-query during the parsing, store it in the object
and show it in the INFORMATION_SCHEMA.
Basically, the idea is to create a copy of the original query convert it to
UTF8. Character set introducers are removed and all text literals are
converted to UTF8.
This UTF8 query is intended to provide user-readable output. It must not be
used to recreate the object. Specialized SHOW CREATE statements should be
used for this.
The reason for this limitation is the following: the original query can
contain symbols from several character sets (by means of character set
introducers).
Example:
- original query:
CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1;
- UTF8 query (for INFORMATION_SCHEMA):
CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 19:34:54 +02:00
|
|
|
txt_cs);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
utf_txt.str= txt->str;
|
|
|
|
utf_txt.length= txt->length;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* NOTE: utf_txt.length is in bytes, not in symbols. */
|
|
|
|
|
|
|
|
memcpy(m_body_utf8_ptr, utf_txt.str, utf_txt.length);
|
|
|
|
m_body_utf8_ptr += utf_txt.length;
|
|
|
|
*m_body_utf8_ptr= 0;
|
|
|
|
|
|
|
|
m_cpp_utf8_processed_ptr= end_ptr;
|
|
|
|
}
|
|
|
|
|
2007-02-04 14:49:24 +01:00
|
|
|
|
2003-02-12 20:55:37 +01:00
|
|
|
/*
|
|
|
|
This is called before every query that is to be parsed.
|
|
|
|
Because of this, it's critical to not do too much things here.
|
|
|
|
(We already do too much here)
|
|
|
|
*/
|
|
|
|
|
2007-04-26 05:38:12 +02:00
|
|
|
void lex_start(THD *thd)
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2003-05-05 20:54:37 +02:00
|
|
|
LEX *lex= thd->lex;
|
2005-02-05 15:05:46 +01:00
|
|
|
DBUG_ENTER("lex_start");
|
|
|
|
|
|
|
|
lex->thd= lex->unit.thd= thd;
|
|
|
|
|
2005-08-12 16:57:19 +02:00
|
|
|
lex->context_stack.empty();
|
2004-10-14 00:53:59 +02:00
|
|
|
lex->unit.init_query();
|
|
|
|
lex->unit.init_select();
|
2005-08-12 16:57:19 +02:00
|
|
|
/* 'parent_lex' is used in init_query() so it must be before it. */
|
|
|
|
lex->select_lex.parent_lex= lex;
|
2004-10-14 00:53:59 +02:00
|
|
|
lex->select_lex.init_query();
|
|
|
|
lex->value_list.empty();
|
2004-12-13 13:26:28 +01:00
|
|
|
lex->update_list.empty();
|
2008-09-18 10:38:44 +02:00
|
|
|
lex->set_var_list.empty();
|
2004-10-14 00:53:59 +02:00
|
|
|
lex->param_list.empty();
|
2004-10-29 18:26:52 +02:00
|
|
|
lex->view_list.empty();
|
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->prepared_stmt_params.empty();
|
2006-07-11 21:39:51 +02:00
|
|
|
lex->auxiliary_table_list.empty();
|
2004-10-14 00:53:59 +02:00
|
|
|
lex->unit.next= lex->unit.master=
|
|
|
|
lex->unit.link_next= lex->unit.return_to= 0;
|
|
|
|
lex->unit.prev= lex->unit.link_prev= 0;
|
|
|
|
lex->unit.slave= lex->unit.global_parameters= lex->current_select=
|
|
|
|
lex->all_selects_list= &lex->select_lex;
|
|
|
|
lex->select_lex.master= &lex->unit;
|
|
|
|
lex->select_lex.prev= &lex->unit.slave;
|
|
|
|
lex->select_lex.link_next= lex->select_lex.slave= lex->select_lex.next= 0;
|
|
|
|
lex->select_lex.link_prev= (st_select_lex_node**)&(lex->all_selects_list);
|
|
|
|
lex->select_lex.options= 0;
|
2006-06-27 19:28:32 +02:00
|
|
|
lex->select_lex.sql_cache= SELECT_LEX::SQL_CACHE_UNSPECIFIED;
|
2004-10-29 18:26:52 +02:00
|
|
|
lex->select_lex.init_order();
|
|
|
|
lex->select_lex.group_list.empty();
|
2004-10-14 00:53:59 +02:00
|
|
|
lex->describe= 0;
|
2004-12-06 16:15:54 +01:00
|
|
|
lex->subqueries= FALSE;
|
2004-10-29 18:26:52 +02:00
|
|
|
lex->view_prepare_mode= FALSE;
|
2004-12-06 16:15:54 +01:00
|
|
|
lex->derived_tables= 0;
|
2004-10-14 00:53:59 +02:00
|
|
|
lex->safe_to_cache_query= 1;
|
2006-05-30 07:45:23 +02:00
|
|
|
lex->leaf_tables_insert= 0;
|
2007-02-04 14:49:24 +01:00
|
|
|
lex->parsing_options.reset();
|
2004-10-29 18:26:52 +02:00
|
|
|
lex->empty_field_list_on_rset= 0;
|
2004-10-14 00:53:59 +02:00
|
|
|
lex->select_lex.select_number= 1;
|
2000-07-31 21:29:14 +02:00
|
|
|
lex->length=0;
|
2005-07-18 13:31:02 +02:00
|
|
|
lex->part_info= 0;
|
2002-10-03 15:35:08 +02:00
|
|
|
lex->select_lex.in_sum_expr=0;
|
2002-10-04 13:15:59 +02:00
|
|
|
lex->select_lex.ftfunc_list_alloc.empty();
|
2002-10-30 12:18:52 +01:00
|
|
|
lex->select_lex.ftfunc_list= &lex->select_lex.ftfunc_list_alloc;
|
2004-01-21 12:47:47 +01:00
|
|
|
lex->select_lex.group_list.empty();
|
|
|
|
lex->select_lex.order_list.empty();
|
2003-06-25 00:19:09 +02:00
|
|
|
lex->duplicates= DUP_ERROR;
|
2004-12-31 11:04:35 +01:00
|
|
|
lex->ignore= 0;
|
2006-07-13 10:59:58 +02:00
|
|
|
lex->spname= NULL;
|
Simplistic, experimental framework for Stored Procedures (SPs).
Implements creation and dropping of PROCEDUREs, IN, OUT, and INOUT parameters,
single-statement procedures, rudimentary multi-statement (begin-end) prodedures
(when the client can handle it), and local variables.
Missing most of the embedded SQL language, all attributes, FUNCTIONs, error handling,
reparses procedures at each call (no caching), etc, etc.
Certainly buggy too, but procedures can actually be created and called....
2002-12-08 19:59:22 +01:00
|
|
|
lex->sphead= NULL;
|
|
|
|
lex->spcont= NULL;
|
2004-11-05 16:29:47 +01:00
|
|
|
lex->proc_list.first= 0;
|
2006-06-29 00:42:25 +02:00
|
|
|
lex->escape_used= FALSE;
|
2007-03-02 17:43:45 +01:00
|
|
|
lex->query_tables= 0;
|
2006-05-30 07:45:23 +02:00
|
|
|
lex->reset_query_tables_list(FALSE);
|
2006-08-23 16:53:04 +02:00
|
|
|
lex->expr_allows_subselect= TRUE;
|
2007-10-09 16:16:39 +02:00
|
|
|
lex->use_only_table_context= FALSE;
|
2005-12-02 13:07:02 +01:00
|
|
|
|
2006-10-16 18:57:33 +02:00
|
|
|
lex->name.str= 0;
|
|
|
|
lex->name.length= 0;
|
2006-06-29 00:42:25 +02:00
|
|
|
lex->event_parse_data= NULL;
|
2007-01-03 23:15:10 +01:00
|
|
|
lex->profile_options= PROFILE_NONE;
|
2005-10-15 23:32:37 +02:00
|
|
|
lex->nest_level=0 ;
|
|
|
|
lex->allow_sum_func= 0;
|
|
|
|
lex->in_sum_func= NULL;
|
2009-04-03 21:11:54 +02:00
|
|
|
lex->protect_against_global_read_lock= FALSE;
|
2006-12-02 01:47:45 +01:00
|
|
|
/*
|
|
|
|
ok, there must be a better solution for this, long-term
|
|
|
|
I tried "bzero" in the sql_yacc.yy code, but that for
|
|
|
|
some reason made the values zero, even if they were set
|
|
|
|
*/
|
|
|
|
lex->server_options.server_name= 0;
|
|
|
|
lex->server_options.server_name_length= 0;
|
|
|
|
lex->server_options.host= 0;
|
|
|
|
lex->server_options.db= 0;
|
|
|
|
lex->server_options.username= 0;
|
|
|
|
lex->server_options.password= 0;
|
|
|
|
lex->server_options.scheme= 0;
|
|
|
|
lex->server_options.socket= 0;
|
|
|
|
lex->server_options.owner= 0;
|
|
|
|
lex->server_options.port= -1;
|
Patch for the following bugs:
- BUG#11986: Stored routines and triggers can fail if the code
has a non-ascii symbol
- BUG#16291: mysqldump corrupts string-constants with non-ascii-chars
- BUG#19443: INFORMATION_SCHEMA does not support charsets properly
- BUG#21249: Character set of SP-var can be ignored
- BUG#25212: Character set of string constant is ignored (stored routines)
- BUG#25221: Character set of string constant is ignored (triggers)
There were a few general problems that caused these bugs:
1. Character set information of the original (definition) query for views,
triggers, stored routines and events was lost.
2. mysqldump output query in client character set, which can be
inappropriate to encode definition-query.
3. INFORMATION_SCHEMA used strings with mixed encodings to display object
definition;
1. No query-definition-character set.
In order to compile query into execution code, some extra data (such as
environment variables or the database character set) is used. The problem
here was that this context was not preserved. So, on the next load it can
differ from the original one, thus the result will be different.
The context contains the following data:
- client character set;
- connection collation (character set and collation);
- collation of the owner database;
The fix is to store this context and use it each time we parse (compile)
and execute the object (stored routine, trigger, ...).
2. Wrong mysqldump-output.
The original query can contain several encodings (by means of character set
introducers). The problem here was that we tried to convert original query
to the mysqldump-client character set.
Moreover, we stored queries in different character sets for different
objects (views, for one, used UTF8, triggers used original character set).
The solution is
- to store definition queries in the original character set;
- to change SHOW CREATE statement to output definition query in the
binary character set (i.e. without any conversion);
- introduce SHOW CREATE TRIGGER statement;
- to dump special statements to switch the context to the original one
before dumping and restore it afterwards.
Note, in order to preserve the database collation at the creation time,
additional ALTER DATABASE might be used (to temporary switch the database
collation back to the original value). In this case, ALTER DATABASE
privilege will be required. This is a backward-incompatible change.
3. INFORMATION_SCHEMA showed non-UTF8 strings
The fix is to generate UTF8-query during the parsing, store it in the object
and show it in the INFORMATION_SCHEMA.
Basically, the idea is to create a copy of the original query convert it to
UTF8. Character set introducers are removed and all text literals are
converted to UTF8.
This UTF8 query is intended to provide user-readable output. It must not be
used to recreate the object. Specialized SHOW CREATE statements should be
used for this.
The reason for this limitation is the following: the original query can
contain symbols from several character sets (by means of character set
introducers).
Example:
- original query:
CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1;
- UTF8 query (for INFORMATION_SCHEMA):
CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 19:34:54 +02:00
|
|
|
|
2007-11-05 16:25:40 +01:00
|
|
|
lex->is_lex_started= TRUE;
|
2005-02-05 15:05:46 +01:00
|
|
|
DBUG_VOID_RETURN;
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
void lex_end(LEX *lex)
|
|
|
|
{
|
2006-05-04 18:39:47 +02:00
|
|
|
DBUG_ENTER("lex_end");
|
2006-05-04 21:19:31 +02:00
|
|
|
DBUG_PRINT("enter", ("lex: 0x%lx", (long) lex));
|
2007-03-02 17:43:45 +01:00
|
|
|
|
|
|
|
/* release used plugins */
|
|
|
|
plugin_unlock_list(0, (plugin_ref*)lex->plugins.buffer,
|
|
|
|
lex->plugins.elements);
|
|
|
|
reset_dynamic(&lex->plugins);
|
|
|
|
|
2006-05-04 18:39:47 +02:00
|
|
|
DBUG_VOID_RETURN;
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
|
|
|
|
2008-07-14 23:41:30 +02:00
|
|
|
Yacc_state::~Yacc_state()
|
|
|
|
{
|
|
|
|
if (yacc_yyss)
|
|
|
|
{
|
2008-07-15 03:43:12 +02:00
|
|
|
my_free(yacc_yyss, MYF(0));
|
|
|
|
my_free(yacc_yyvs, MYF(0));
|
2008-07-14 23:41:30 +02:00
|
|
|
}
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
|
|
|
|
2007-04-26 05:38:12 +02:00
|
|
|
static int find_keyword(Lex_input_stream *lip, uint len, bool function)
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
const char *tok= lip->get_tok_start();
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2007-03-27 19:09:56 +02:00
|
|
|
SYMBOL *symbol= get_hash_symbol(tok, len, function);
|
2000-07-31 21:29:14 +02:00
|
|
|
if (symbol)
|
|
|
|
{
|
2007-04-26 05:38:12 +02:00
|
|
|
lip->yylval->symbol.symbol=symbol;
|
|
|
|
lip->yylval->symbol.str= (char*) tok;
|
|
|
|
lip->yylval->symbol.length=len;
|
|
|
|
|
2004-11-17 16:49:10 +01:00
|
|
|
if ((symbol->tok == NOT_SYM) &&
|
2007-04-26 05:38:12 +02:00
|
|
|
(lip->m_thd->variables.sql_mode & MODE_HIGH_NOT_PRECEDENCE))
|
2004-11-17 16:49:10 +01:00
|
|
|
return NOT2_SYM;
|
|
|
|
if ((symbol->tok == OR_OR_SYM) &&
|
2007-04-26 05:38:12 +02:00
|
|
|
!(lip->m_thd->variables.sql_mode & MODE_PIPES_AS_CONCAT))
|
2004-11-17 16:49:10 +01:00
|
|
|
return OR2_SYM;
|
2007-04-26 05:38:12 +02:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
return symbol->tok;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2004-02-06 21:57:22 +01:00
|
|
|
/*
|
|
|
|
Check if name is a keyword
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
is_keyword()
|
2006-03-09 01:10:39 +01:00
|
|
|
name checked name (must not be empty)
|
2004-02-06 21:57:22 +01:00
|
|
|
len length of checked name
|
|
|
|
|
|
|
|
RETURN VALUES
|
|
|
|
0 name is a keyword
|
|
|
|
1 name isn't a keyword
|
|
|
|
*/
|
|
|
|
|
|
|
|
bool is_keyword(const char *name, uint len)
|
|
|
|
{
|
2006-03-09 01:10:39 +01:00
|
|
|
DBUG_ASSERT(len != 0);
|
2004-02-06 21:57:22 +01:00
|
|
|
return get_hash_symbol(name,len,0)!=0;
|
|
|
|
}
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2009-05-27 15:05:29 +02:00
|
|
|
/**
|
|
|
|
Check if name is a sql function
|
|
|
|
|
|
|
|
@param name checked name
|
|
|
|
|
2009-05-27 17:19:44 +02:00
|
|
|
@return is this a native function or not
|
2009-05-27 15:05:29 +02:00
|
|
|
@retval 0 name is a function
|
|
|
|
@retval 1 name isn't a function
|
|
|
|
*/
|
|
|
|
|
Bug#18239 (Possible to overload internal functions with stored functions)
Bug#21025 (misleading error message when creating functions named 'x', or 'y')
Bug#22619 (Spaces considered harmful)
This change contains a fix to report warnings or errors, and multiple tests
cases.
Before this fix, name collisions between:
- Native functions
- User Defined Functions
- Stored Functions
were not systematically reported, leading to confusing behavior.
I) Native / User Defined Function
Before this fix, is was possible to create a UDF named "foo", with the same
name as a native function "foo", but it was impossible to invoke the UDF,
since the syntax "foo()" always refer to the native function.
After this fix, creating a UDF fails with an error if there is a name
collision with a native function.
II) Native / Stored Function
Before this fix, is was possible to create a SF named "db.foo", with the same
name as a native function "foo", but this was confusing since the syntax
"foo()" would refer to the native function. To refer to the Stored Function,
the user had to use the "db.foo()" syntax.
After this fix, creating a Stored Function reports a warning if there is a
name collision with a native function.
III) User Defined Function / Stored Function
Before this fix, creating a User Defined Function "foo" and a Stored Function
"db.foo" are mutually exclusive operations. Whenever the second function is
created, an error is reported. However, the test suite did not cover this
behavior.
After this fix, the behavior is unchanged, and is now covered by test cases.
Note that the code change in this patch depends on the fix for Bug 21114.
2006-11-15 03:34:16 +01:00
|
|
|
bool is_lex_native_function(const LEX_STRING *name)
|
|
|
|
{
|
|
|
|
DBUG_ASSERT(name != NULL);
|
2009-02-13 17:41:47 +01:00
|
|
|
return (get_hash_symbol(name->str, (uint) name->length, 1) != 0);
|
Bug#18239 (Possible to overload internal functions with stored functions)
Bug#21025 (misleading error message when creating functions named 'x', or 'y')
Bug#22619 (Spaces considered harmful)
This change contains a fix to report warnings or errors, and multiple tests
cases.
Before this fix, name collisions between:
- Native functions
- User Defined Functions
- Stored Functions
were not systematically reported, leading to confusing behavior.
I) Native / User Defined Function
Before this fix, is was possible to create a UDF named "foo", with the same
name as a native function "foo", but it was impossible to invoke the UDF,
since the syntax "foo()" always refer to the native function.
After this fix, creating a UDF fails with an error if there is a name
collision with a native function.
II) Native / Stored Function
Before this fix, is was possible to create a SF named "db.foo", with the same
name as a native function "foo", but this was confusing since the syntax
"foo()" would refer to the native function. To refer to the Stored Function,
the user had to use the "db.foo()" syntax.
After this fix, creating a Stored Function reports a warning if there is a
name collision with a native function.
III) User Defined Function / Stored Function
Before this fix, creating a User Defined Function "foo" and a Stored Function
"db.foo" are mutually exclusive operations. Whenever the second function is
created, an error is reported. However, the test suite did not cover this
behavior.
After this fix, the behavior is unchanged, and is now covered by test cases.
Note that the code change in this patch depends on the fix for Bug 21114.
2006-11-15 03:34:16 +01:00
|
|
|
}
|
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
/* make a copy of token before ptr and set yytoklen */
|
|
|
|
|
Bug#21513 (SP having body starting with quoted label rendered unusable)
Before this fix, the parser would sometime change where a token starts by
altering Lex_input_string::tok_start, which later confused the code in
sql_yacc.yy that needs to capture the source code of a SQL statement,
like to represent the body of a stored procedure.
This line of code in sql_lex.cc :
case MY_LEX_USER_VARIABLE_DELIMITER:
lip->tok_start= lip->ptr; // Skip first `
would <skip the first back quote> ... and cause the bug reported.
In general, the responsibility of sql_lex.cc is to *find* where token are
in the SQL text, but is *not* to make up fake or incomplete tokens.
With a quoted label like `my_label`, the token starts on the first quote.
Extracting the token value should not change that (it did).
With this fix, the lexical analysis has been cleaned up to not change
lip->tok_start (in the case found for this bug).
The functions get_token() and get_quoted_token() now have an extra
parameters, used when some characters from the beginning of the token need
to be skipped when extracting a token value, like when extracting 'AB' from
'0xAB', for example, for a HEX_NUM token.
This exposed a bad assumption in Item_hex_string and Item_bin_string,
which has been fixed:
The assumption was that the string given, 'AB', was in fact preceded in
memory by '0x', which might be false (it can be preceded by "x'" and
followed by "'" -- or not be preceded by valid memory at all)
If a name is needed for Item_hex_string or Item_bin_string, the name is
taken from the original and true source code ('0xAB'), and assigned in
the select_item rule, instead of relying on assumptions related to how
memory is used.
2007-04-28 01:14:25 +02:00
|
|
|
static LEX_STRING get_token(Lex_input_stream *lip, uint skip, uint length)
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
|
|
|
LEX_STRING tmp;
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
lip->yyUnget(); // ptr points now after last token char
|
2007-04-26 05:38:12 +02:00
|
|
|
tmp.length=lip->yytoklen=length;
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
tmp.str= lip->m_thd->strmake(lip->get_tok_start() + skip, tmp.length);
|
Patch for the following bugs:
- BUG#11986: Stored routines and triggers can fail if the code
has a non-ascii symbol
- BUG#16291: mysqldump corrupts string-constants with non-ascii-chars
- BUG#19443: INFORMATION_SCHEMA does not support charsets properly
- BUG#21249: Character set of SP-var can be ignored
- BUG#25212: Character set of string constant is ignored (stored routines)
- BUG#25221: Character set of string constant is ignored (triggers)
There were a few general problems that caused these bugs:
1. Character set information of the original (definition) query for views,
triggers, stored routines and events was lost.
2. mysqldump output query in client character set, which can be
inappropriate to encode definition-query.
3. INFORMATION_SCHEMA used strings with mixed encodings to display object
definition;
1. No query-definition-character set.
In order to compile query into execution code, some extra data (such as
environment variables or the database character set) is used. The problem
here was that this context was not preserved. So, on the next load it can
differ from the original one, thus the result will be different.
The context contains the following data:
- client character set;
- connection collation (character set and collation);
- collation of the owner database;
The fix is to store this context and use it each time we parse (compile)
and execute the object (stored routine, trigger, ...).
2. Wrong mysqldump-output.
The original query can contain several encodings (by means of character set
introducers). The problem here was that we tried to convert original query
to the mysqldump-client character set.
Moreover, we stored queries in different character sets for different
objects (views, for one, used UTF8, triggers used original character set).
The solution is
- to store definition queries in the original character set;
- to change SHOW CREATE statement to output definition query in the
binary character set (i.e. without any conversion);
- introduce SHOW CREATE TRIGGER statement;
- to dump special statements to switch the context to the original one
before dumping and restore it afterwards.
Note, in order to preserve the database collation at the creation time,
additional ALTER DATABASE might be used (to temporary switch the database
collation back to the original value). In this case, ALTER DATABASE
privilege will be required. This is a backward-incompatible change.
3. INFORMATION_SCHEMA showed non-UTF8 strings
The fix is to generate UTF8-query during the parsing, store it in the object
and show it in the INFORMATION_SCHEMA.
Basically, the idea is to create a copy of the original query convert it to
UTF8. Character set introducers are removed and all text literals are
converted to UTF8.
This UTF8 query is intended to provide user-readable output. It must not be
used to recreate the object. Specialized SHOW CREATE statements should be
used for this.
The reason for this limitation is the following: the original query can
contain symbols from several character sets (by means of character set
introducers).
Example:
- original query:
CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1;
- UTF8 query (for INFORMATION_SCHEMA):
CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 19:34:54 +02:00
|
|
|
|
|
|
|
lip->m_cpp_text_start= lip->get_cpp_tok_start() + skip;
|
|
|
|
lip->m_cpp_text_end= lip->m_cpp_text_start + tmp.length;
|
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
return tmp;
|
|
|
|
}
|
|
|
|
|
2004-02-10 21:47:18 +01:00
|
|
|
/*
|
|
|
|
todo:
|
|
|
|
There are no dangerous charsets in mysql for function
|
|
|
|
get_quoted_token yet. But it should be fixed in the
|
|
|
|
future to operate multichar strings (like ucs2)
|
|
|
|
*/
|
|
|
|
|
2007-04-26 05:38:12 +02:00
|
|
|
static LEX_STRING get_quoted_token(Lex_input_stream *lip,
|
Bug#21513 (SP having body starting with quoted label rendered unusable)
Before this fix, the parser would sometime change where a token starts by
altering Lex_input_string::tok_start, which later confused the code in
sql_yacc.yy that needs to capture the source code of a SQL statement,
like to represent the body of a stored procedure.
This line of code in sql_lex.cc :
case MY_LEX_USER_VARIABLE_DELIMITER:
lip->tok_start= lip->ptr; // Skip first `
would <skip the first back quote> ... and cause the bug reported.
In general, the responsibility of sql_lex.cc is to *find* where token are
in the SQL text, but is *not* to make up fake or incomplete tokens.
With a quoted label like `my_label`, the token starts on the first quote.
Extracting the token value should not change that (it did).
With this fix, the lexical analysis has been cleaned up to not change
lip->tok_start (in the case found for this bug).
The functions get_token() and get_quoted_token() now have an extra
parameters, used when some characters from the beginning of the token need
to be skipped when extracting a token value, like when extracting 'AB' from
'0xAB', for example, for a HEX_NUM token.
This exposed a bad assumption in Item_hex_string and Item_bin_string,
which has been fixed:
The assumption was that the string given, 'AB', was in fact preceded in
memory by '0x', which might be false (it can be preceded by "x'" and
followed by "'" -- or not be preceded by valid memory at all)
If a name is needed for Item_hex_string or Item_bin_string, the name is
taken from the original and true source code ('0xAB'), and assigned in
the select_item rule, instead of relying on assumptions related to how
memory is used.
2007-04-28 01:14:25 +02:00
|
|
|
uint skip,
|
2007-04-26 05:38:12 +02:00
|
|
|
uint length, char quote)
|
2002-12-01 13:59:06 +01:00
|
|
|
{
|
|
|
|
LEX_STRING tmp;
|
2007-03-27 19:09:56 +02:00
|
|
|
const char *from, *end;
|
|
|
|
char *to;
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
lip->yyUnget(); // ptr points now after last token char
|
2007-04-26 05:38:12 +02:00
|
|
|
tmp.length= lip->yytoklen=length;
|
|
|
|
tmp.str=(char*) lip->m_thd->alloc(tmp.length+1);
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
from= lip->get_tok_start() + skip;
|
2007-04-30 19:41:51 +02:00
|
|
|
to= tmp.str;
|
Bug#21513 (SP having body starting with quoted label rendered unusable)
Before this fix, the parser would sometime change where a token starts by
altering Lex_input_string::tok_start, which later confused the code in
sql_yacc.yy that needs to capture the source code of a SQL statement,
like to represent the body of a stored procedure.
This line of code in sql_lex.cc :
case MY_LEX_USER_VARIABLE_DELIMITER:
lip->tok_start= lip->ptr; // Skip first `
would <skip the first back quote> ... and cause the bug reported.
In general, the responsibility of sql_lex.cc is to *find* where token are
in the SQL text, but is *not* to make up fake or incomplete tokens.
With a quoted label like `my_label`, the token starts on the first quote.
Extracting the token value should not change that (it did).
With this fix, the lexical analysis has been cleaned up to not change
lip->tok_start (in the case found for this bug).
The functions get_token() and get_quoted_token() now have an extra
parameters, used when some characters from the beginning of the token need
to be skipped when extracting a token value, like when extracting 'AB' from
'0xAB', for example, for a HEX_NUM token.
This exposed a bad assumption in Item_hex_string and Item_bin_string,
which has been fixed:
The assumption was that the string given, 'AB', was in fact preceded in
memory by '0x', which might be false (it can be preceded by "x'" and
followed by "'" -- or not be preceded by valid memory at all)
If a name is needed for Item_hex_string or Item_bin_string, the name is
taken from the original and true source code ('0xAB'), and assigned in
the select_item rule, instead of relying on assumptions related to how
memory is used.
2007-04-28 01:14:25 +02:00
|
|
|
end= to+length;
|
Patch for the following bugs:
- BUG#11986: Stored routines and triggers can fail if the code
has a non-ascii symbol
- BUG#16291: mysqldump corrupts string-constants with non-ascii-chars
- BUG#19443: INFORMATION_SCHEMA does not support charsets properly
- BUG#21249: Character set of SP-var can be ignored
- BUG#25212: Character set of string constant is ignored (stored routines)
- BUG#25221: Character set of string constant is ignored (triggers)
There were a few general problems that caused these bugs:
1. Character set information of the original (definition) query for views,
triggers, stored routines and events was lost.
2. mysqldump output query in client character set, which can be
inappropriate to encode definition-query.
3. INFORMATION_SCHEMA used strings with mixed encodings to display object
definition;
1. No query-definition-character set.
In order to compile query into execution code, some extra data (such as
environment variables or the database character set) is used. The problem
here was that this context was not preserved. So, on the next load it can
differ from the original one, thus the result will be different.
The context contains the following data:
- client character set;
- connection collation (character set and collation);
- collation of the owner database;
The fix is to store this context and use it each time we parse (compile)
and execute the object (stored routine, trigger, ...).
2. Wrong mysqldump-output.
The original query can contain several encodings (by means of character set
introducers). The problem here was that we tried to convert original query
to the mysqldump-client character set.
Moreover, we stored queries in different character sets for different
objects (views, for one, used UTF8, triggers used original character set).
The solution is
- to store definition queries in the original character set;
- to change SHOW CREATE statement to output definition query in the
binary character set (i.e. without any conversion);
- introduce SHOW CREATE TRIGGER statement;
- to dump special statements to switch the context to the original one
before dumping and restore it afterwards.
Note, in order to preserve the database collation at the creation time,
additional ALTER DATABASE might be used (to temporary switch the database
collation back to the original value). In this case, ALTER DATABASE
privilege will be required. This is a backward-incompatible change.
3. INFORMATION_SCHEMA showed non-UTF8 strings
The fix is to generate UTF8-query during the parsing, store it in the object
and show it in the INFORMATION_SCHEMA.
Basically, the idea is to create a copy of the original query convert it to
UTF8. Character set introducers are removed and all text literals are
converted to UTF8.
This UTF8 query is intended to provide user-readable output. It must not be
used to recreate the object. Specialized SHOW CREATE statements should be
used for this.
The reason for this limitation is the following: the original query can
contain symbols from several character sets (by means of character set
introducers).
Example:
- original query:
CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1;
- UTF8 query (for INFORMATION_SCHEMA):
CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 19:34:54 +02:00
|
|
|
|
|
|
|
lip->m_cpp_text_start= lip->get_cpp_tok_start() + skip;
|
|
|
|
lip->m_cpp_text_end= lip->m_cpp_text_start + length;
|
|
|
|
|
Bug#21513 (SP having body starting with quoted label rendered unusable)
Before this fix, the parser would sometime change where a token starts by
altering Lex_input_string::tok_start, which later confused the code in
sql_yacc.yy that needs to capture the source code of a SQL statement,
like to represent the body of a stored procedure.
This line of code in sql_lex.cc :
case MY_LEX_USER_VARIABLE_DELIMITER:
lip->tok_start= lip->ptr; // Skip first `
would <skip the first back quote> ... and cause the bug reported.
In general, the responsibility of sql_lex.cc is to *find* where token are
in the SQL text, but is *not* to make up fake or incomplete tokens.
With a quoted label like `my_label`, the token starts on the first quote.
Extracting the token value should not change that (it did).
With this fix, the lexical analysis has been cleaned up to not change
lip->tok_start (in the case found for this bug).
The functions get_token() and get_quoted_token() now have an extra
parameters, used when some characters from the beginning of the token need
to be skipped when extracting a token value, like when extracting 'AB' from
'0xAB', for example, for a HEX_NUM token.
This exposed a bad assumption in Item_hex_string and Item_bin_string,
which has been fixed:
The assumption was that the string given, 'AB', was in fact preceded in
memory by '0x', which might be false (it can be preceded by "x'" and
followed by "'" -- or not be preceded by valid memory at all)
If a name is needed for Item_hex_string or Item_bin_string, the name is
taken from the original and true source code ('0xAB'), and assigned in
the select_item rule, instead of relying on assumptions related to how
memory is used.
2007-04-28 01:14:25 +02:00
|
|
|
for ( ; to != end; )
|
2002-12-01 13:59:06 +01:00
|
|
|
{
|
2007-03-27 19:09:56 +02:00
|
|
|
if ((*to++= *from++) == quote)
|
Patch for the following bugs:
- BUG#11986: Stored routines and triggers can fail if the code
has a non-ascii symbol
- BUG#16291: mysqldump corrupts string-constants with non-ascii-chars
- BUG#19443: INFORMATION_SCHEMA does not support charsets properly
- BUG#21249: Character set of SP-var can be ignored
- BUG#25212: Character set of string constant is ignored (stored routines)
- BUG#25221: Character set of string constant is ignored (triggers)
There were a few general problems that caused these bugs:
1. Character set information of the original (definition) query for views,
triggers, stored routines and events was lost.
2. mysqldump output query in client character set, which can be
inappropriate to encode definition-query.
3. INFORMATION_SCHEMA used strings with mixed encodings to display object
definition;
1. No query-definition-character set.
In order to compile query into execution code, some extra data (such as
environment variables or the database character set) is used. The problem
here was that this context was not preserved. So, on the next load it can
differ from the original one, thus the result will be different.
The context contains the following data:
- client character set;
- connection collation (character set and collation);
- collation of the owner database;
The fix is to store this context and use it each time we parse (compile)
and execute the object (stored routine, trigger, ...).
2. Wrong mysqldump-output.
The original query can contain several encodings (by means of character set
introducers). The problem here was that we tried to convert original query
to the mysqldump-client character set.
Moreover, we stored queries in different character sets for different
objects (views, for one, used UTF8, triggers used original character set).
The solution is
- to store definition queries in the original character set;
- to change SHOW CREATE statement to output definition query in the
binary character set (i.e. without any conversion);
- introduce SHOW CREATE TRIGGER statement;
- to dump special statements to switch the context to the original one
before dumping and restore it afterwards.
Note, in order to preserve the database collation at the creation time,
additional ALTER DATABASE might be used (to temporary switch the database
collation back to the original value). In this case, ALTER DATABASE
privilege will be required. This is a backward-incompatible change.
3. INFORMATION_SCHEMA showed non-UTF8 strings
The fix is to generate UTF8-query during the parsing, store it in the object
and show it in the INFORMATION_SCHEMA.
Basically, the idea is to create a copy of the original query convert it to
UTF8. Character set introducers are removed and all text literals are
converted to UTF8.
This UTF8 query is intended to provide user-readable output. It must not be
used to recreate the object. Specialized SHOW CREATE statements should be
used for this.
The reason for this limitation is the following: the original query can
contain symbols from several character sets (by means of character set
introducers).
Example:
- original query:
CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1;
- UTF8 query (for INFORMATION_SCHEMA):
CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 19:34:54 +02:00
|
|
|
{
|
2002-12-01 13:59:06 +01:00
|
|
|
from++; // Skip double quotes
|
Patch for the following bugs:
- BUG#11986: Stored routines and triggers can fail if the code
has a non-ascii symbol
- BUG#16291: mysqldump corrupts string-constants with non-ascii-chars
- BUG#19443: INFORMATION_SCHEMA does not support charsets properly
- BUG#21249: Character set of SP-var can be ignored
- BUG#25212: Character set of string constant is ignored (stored routines)
- BUG#25221: Character set of string constant is ignored (triggers)
There were a few general problems that caused these bugs:
1. Character set information of the original (definition) query for views,
triggers, stored routines and events was lost.
2. mysqldump output query in client character set, which can be
inappropriate to encode definition-query.
3. INFORMATION_SCHEMA used strings with mixed encodings to display object
definition;
1. No query-definition-character set.
In order to compile query into execution code, some extra data (such as
environment variables or the database character set) is used. The problem
here was that this context was not preserved. So, on the next load it can
differ from the original one, thus the result will be different.
The context contains the following data:
- client character set;
- connection collation (character set and collation);
- collation of the owner database;
The fix is to store this context and use it each time we parse (compile)
and execute the object (stored routine, trigger, ...).
2. Wrong mysqldump-output.
The original query can contain several encodings (by means of character set
introducers). The problem here was that we tried to convert original query
to the mysqldump-client character set.
Moreover, we stored queries in different character sets for different
objects (views, for one, used UTF8, triggers used original character set).
The solution is
- to store definition queries in the original character set;
- to change SHOW CREATE statement to output definition query in the
binary character set (i.e. without any conversion);
- introduce SHOW CREATE TRIGGER statement;
- to dump special statements to switch the context to the original one
before dumping and restore it afterwards.
Note, in order to preserve the database collation at the creation time,
additional ALTER DATABASE might be used (to temporary switch the database
collation back to the original value). In this case, ALTER DATABASE
privilege will be required. This is a backward-incompatible change.
3. INFORMATION_SCHEMA showed non-UTF8 strings
The fix is to generate UTF8-query during the parsing, store it in the object
and show it in the INFORMATION_SCHEMA.
Basically, the idea is to create a copy of the original query convert it to
UTF8. Character set introducers are removed and all text literals are
converted to UTF8.
This UTF8 query is intended to provide user-readable output. It must not be
used to recreate the object. Specialized SHOW CREATE statements should be
used for this.
The reason for this limitation is the following: the original query can
contain symbols from several character sets (by means of character set
introducers).
Example:
- original query:
CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1;
- UTF8 query (for INFORMATION_SCHEMA):
CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 19:34:54 +02:00
|
|
|
lip->m_cpp_text_start++;
|
|
|
|
}
|
2002-12-01 13:59:06 +01:00
|
|
|
}
|
|
|
|
*to= 0; // End null for safety
|
|
|
|
return tmp;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
Return an unescaped text literal without quotes
|
|
|
|
Fix sometimes to do only one scan of the string
|
|
|
|
*/
|
2000-07-31 21:29:14 +02:00
|
|
|
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
static char *get_text(Lex_input_stream *lip, int pre_skip, int post_skip)
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
|
|
|
reg1 uchar c,sep;
|
|
|
|
uint found_escape=0;
|
2007-04-26 05:38:12 +02:00
|
|
|
CHARSET_INFO *cs= lip->m_thd->charset();
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2007-08-03 12:25:23 +02:00
|
|
|
lip->tok_bitmap= 0;
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
sep= lip->yyGetLast(); // String should end with this
|
|
|
|
while (! lip->eof())
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
c= lip->yyGet();
|
2007-08-03 12:25:23 +02:00
|
|
|
lip->tok_bitmap|= c;
|
2000-07-31 21:29:14 +02:00
|
|
|
#ifdef USE_MB
|
2006-12-14 23:51:37 +01:00
|
|
|
{
|
|
|
|
int l;
|
|
|
|
if (use_mb(cs) &&
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
(l = my_ismbchar(cs,
|
|
|
|
lip->get_ptr() -1,
|
|
|
|
lip->get_end_of_query()))) {
|
|
|
|
lip->skip_binary(l-1);
|
|
|
|
continue;
|
2006-12-14 23:51:37 +01:00
|
|
|
}
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
|
|
|
#endif
|
2004-07-07 14:26:43 +02:00
|
|
|
if (c == '\\' &&
|
2007-04-26 05:38:12 +02:00
|
|
|
!(lip->m_thd->variables.sql_mode & MODE_NO_BACKSLASH_ESCAPES))
|
2000-07-31 21:29:14 +02:00
|
|
|
{ // Escaped character
|
|
|
|
found_escape=1;
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
if (lip->eof())
|
2000-07-31 21:29:14 +02:00
|
|
|
return 0;
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
lip->yySkip();
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
|
|
|
else if (c == sep)
|
|
|
|
{
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
if (c == lip->yyGet()) // Check if two separators in a row
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
found_escape=1; // duplicate. Remember for delete
|
2000-07-31 21:29:14 +02:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
else
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
lip->yyUnget();
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
/* Found end. Unescape and return string */
|
2007-03-27 19:09:56 +02:00
|
|
|
const char *str, *end;
|
|
|
|
char *start;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
str= lip->get_tok_start();
|
|
|
|
end= lip->get_ptr();
|
|
|
|
/* Extract the text from the token */
|
|
|
|
str += pre_skip;
|
|
|
|
end -= post_skip;
|
|
|
|
DBUG_ASSERT(end >= str);
|
|
|
|
|
2007-04-26 05:38:12 +02:00
|
|
|
if (!(start= (char*) lip->m_thd->alloc((uint) (end-str)+1)))
|
2001-03-11 20:20:15 +01:00
|
|
|
return (char*) ""; // Sql_alloc has set error flag
|
Patch for the following bugs:
- BUG#11986: Stored routines and triggers can fail if the code
has a non-ascii symbol
- BUG#16291: mysqldump corrupts string-constants with non-ascii-chars
- BUG#19443: INFORMATION_SCHEMA does not support charsets properly
- BUG#21249: Character set of SP-var can be ignored
- BUG#25212: Character set of string constant is ignored (stored routines)
- BUG#25221: Character set of string constant is ignored (triggers)
There were a few general problems that caused these bugs:
1. Character set information of the original (definition) query for views,
triggers, stored routines and events was lost.
2. mysqldump output query in client character set, which can be
inappropriate to encode definition-query.
3. INFORMATION_SCHEMA used strings with mixed encodings to display object
definition;
1. No query-definition-character set.
In order to compile query into execution code, some extra data (such as
environment variables or the database character set) is used. The problem
here was that this context was not preserved. So, on the next load it can
differ from the original one, thus the result will be different.
The context contains the following data:
- client character set;
- connection collation (character set and collation);
- collation of the owner database;
The fix is to store this context and use it each time we parse (compile)
and execute the object (stored routine, trigger, ...).
2. Wrong mysqldump-output.
The original query can contain several encodings (by means of character set
introducers). The problem here was that we tried to convert original query
to the mysqldump-client character set.
Moreover, we stored queries in different character sets for different
objects (views, for one, used UTF8, triggers used original character set).
The solution is
- to store definition queries in the original character set;
- to change SHOW CREATE statement to output definition query in the
binary character set (i.e. without any conversion);
- introduce SHOW CREATE TRIGGER statement;
- to dump special statements to switch the context to the original one
before dumping and restore it afterwards.
Note, in order to preserve the database collation at the creation time,
additional ALTER DATABASE might be used (to temporary switch the database
collation back to the original value). In this case, ALTER DATABASE
privilege will be required. This is a backward-incompatible change.
3. INFORMATION_SCHEMA showed non-UTF8 strings
The fix is to generate UTF8-query during the parsing, store it in the object
and show it in the INFORMATION_SCHEMA.
Basically, the idea is to create a copy of the original query convert it to
UTF8. Character set introducers are removed and all text literals are
converted to UTF8.
This UTF8 query is intended to provide user-readable output. It must not be
used to recreate the object. Specialized SHOW CREATE statements should be
used for this.
The reason for this limitation is the following: the original query can
contain symbols from several character sets (by means of character set
introducers).
Example:
- original query:
CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1;
- UTF8 query (for INFORMATION_SCHEMA):
CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 19:34:54 +02:00
|
|
|
|
|
|
|
lip->m_cpp_text_start= lip->get_cpp_tok_start() + pre_skip;
|
|
|
|
lip->m_cpp_text_end= lip->get_cpp_ptr() - post_skip;
|
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
if (!found_escape)
|
|
|
|
{
|
2007-04-26 05:38:12 +02:00
|
|
|
lip->yytoklen=(uint) (end-str);
|
|
|
|
memcpy(start,str,lip->yytoklen);
|
|
|
|
start[lip->yytoklen]=0;
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2007-03-27 19:09:56 +02:00
|
|
|
char *to;
|
2005-02-04 01:07:32 +01:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
for (to=start ; str != end ; str++)
|
|
|
|
{
|
|
|
|
#ifdef USE_MB
|
|
|
|
int l;
|
2003-03-15 12:19:06 +01:00
|
|
|
if (use_mb(cs) &&
|
2007-03-27 19:09:56 +02:00
|
|
|
(l = my_ismbchar(cs, str, end))) {
|
2000-07-31 21:29:14 +02:00
|
|
|
while (l--)
|
|
|
|
*to++ = *str++;
|
|
|
|
str--;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
#endif
|
2007-04-26 05:38:12 +02:00
|
|
|
if (!(lip->m_thd->variables.sql_mode & MODE_NO_BACKSLASH_ESCAPES) &&
|
2005-02-04 01:14:02 +01:00
|
|
|
*str == '\\' && str+1 != end)
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
|
|
|
switch(*++str) {
|
|
|
|
case 'n':
|
|
|
|
*to++='\n';
|
|
|
|
break;
|
|
|
|
case 't':
|
|
|
|
*to++= '\t';
|
|
|
|
break;
|
|
|
|
case 'r':
|
|
|
|
*to++ = '\r';
|
|
|
|
break;
|
|
|
|
case 'b':
|
|
|
|
*to++ = '\b';
|
|
|
|
break;
|
|
|
|
case '0':
|
|
|
|
*to++= 0; // Ascii null
|
|
|
|
break;
|
|
|
|
case 'Z': // ^Z must be escaped on Win32
|
|
|
|
*to++='\032';
|
|
|
|
break;
|
|
|
|
case '_':
|
|
|
|
case '%':
|
|
|
|
*to++= '\\'; // remember prefix for wildcard
|
|
|
|
/* Fall through */
|
|
|
|
default:
|
2006-05-24 00:55:53 +02:00
|
|
|
*to++= *str;
|
2000-07-31 21:29:14 +02:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2006-05-24 00:55:53 +02:00
|
|
|
else if (*str == sep)
|
|
|
|
*to++= *str++; // Two ' or "
|
2000-07-31 21:29:14 +02:00
|
|
|
else
|
|
|
|
*to++ = *str;
|
|
|
|
}
|
|
|
|
*to=0;
|
2007-04-26 05:38:12 +02:00
|
|
|
lip->yytoklen=(uint) (to-start);
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
2007-03-27 19:09:56 +02:00
|
|
|
return start;
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
return 0; // unexpected end of query
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
** Calc type of integer; long integer, longlong integer or real.
|
|
|
|
** Returns smallest type that match the string.
|
|
|
|
** When using unsigned long long values the result is converted to a real
|
|
|
|
** because else they will be unexpected sign changes because all calculation
|
|
|
|
** is done with longlong or double.
|
|
|
|
*/
|
|
|
|
|
|
|
|
static const char *long_str="2147483647";
|
|
|
|
static const uint long_len=10;
|
|
|
|
static const char *signed_long_str="-2147483648";
|
|
|
|
static const char *longlong_str="9223372036854775807";
|
|
|
|
static const uint longlong_len=19;
|
|
|
|
static const char *signed_longlong_str="-9223372036854775808";
|
|
|
|
static const uint signed_longlong_len=19;
|
2001-09-14 01:54:33 +02:00
|
|
|
static const char *unsigned_longlong_str="18446744073709551615";
|
|
|
|
static const uint unsigned_longlong_len=20;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2005-05-25 11:56:47 +02:00
|
|
|
static inline uint int_token(const char *str,uint length)
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
|
|
|
if (length < long_len) // quick normal case
|
|
|
|
return NUM;
|
|
|
|
bool neg=0;
|
|
|
|
|
|
|
|
if (*str == '+') // Remove sign and pre-zeros
|
|
|
|
{
|
|
|
|
str++; length--;
|
|
|
|
}
|
|
|
|
else if (*str == '-')
|
|
|
|
{
|
|
|
|
str++; length--;
|
|
|
|
neg=1;
|
|
|
|
}
|
|
|
|
while (*str == '0' && length)
|
|
|
|
{
|
|
|
|
str++; length --;
|
|
|
|
}
|
|
|
|
if (length < long_len)
|
|
|
|
return NUM;
|
|
|
|
|
|
|
|
uint smaller,bigger;
|
|
|
|
const char *cmp;
|
|
|
|
if (neg)
|
|
|
|
{
|
|
|
|
if (length == long_len)
|
|
|
|
{
|
|
|
|
cmp= signed_long_str+1;
|
|
|
|
smaller=NUM; // If <= signed_long_str
|
|
|
|
bigger=LONG_NUM; // If >= signed_long_str
|
|
|
|
}
|
|
|
|
else if (length < signed_longlong_len)
|
|
|
|
return LONG_NUM;
|
|
|
|
else if (length > signed_longlong_len)
|
2005-02-08 23:50:45 +01:00
|
|
|
return DECIMAL_NUM;
|
2000-07-31 21:29:14 +02:00
|
|
|
else
|
|
|
|
{
|
|
|
|
cmp=signed_longlong_str+1;
|
|
|
|
smaller=LONG_NUM; // If <= signed_longlong_str
|
2005-02-08 23:50:45 +01:00
|
|
|
bigger=DECIMAL_NUM;
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
if (length == long_len)
|
|
|
|
{
|
|
|
|
cmp= long_str;
|
|
|
|
smaller=NUM;
|
|
|
|
bigger=LONG_NUM;
|
|
|
|
}
|
|
|
|
else if (length < longlong_len)
|
|
|
|
return LONG_NUM;
|
|
|
|
else if (length > longlong_len)
|
2001-09-14 01:54:33 +02:00
|
|
|
{
|
|
|
|
if (length > unsigned_longlong_len)
|
2005-02-08 23:50:45 +01:00
|
|
|
return DECIMAL_NUM;
|
2001-09-14 01:54:33 +02:00
|
|
|
cmp=unsigned_longlong_str;
|
|
|
|
smaller=ULONGLONG_NUM;
|
2005-02-08 23:50:45 +01:00
|
|
|
bigger=DECIMAL_NUM;
|
2001-09-14 01:54:33 +02:00
|
|
|
}
|
2000-07-31 21:29:14 +02:00
|
|
|
else
|
|
|
|
{
|
|
|
|
cmp=longlong_str;
|
|
|
|
smaller=LONG_NUM;
|
2003-02-27 01:10:19 +01:00
|
|
|
bigger= ULONGLONG_NUM;
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
while (*cmp && *cmp++ == *str++) ;
|
|
|
|
return ((uchar) str[-1] <= (uchar) cmp[-1]) ? smaller : bigger;
|
|
|
|
}
|
|
|
|
|
2009-04-10 04:18:18 +02:00
|
|
|
|
|
|
|
/**
|
|
|
|
Given a stream that is advanced to the first contained character in
|
|
|
|
an open comment, consume the comment. Optionally, if we are allowed,
|
|
|
|
recurse so that we understand comments within this current comment.
|
|
|
|
|
|
|
|
At this level, we do not support version-condition comments. We might
|
|
|
|
have been called with having just passed one in the stream, though. In
|
|
|
|
that case, we probably want to tolerate mundane comments inside. Thus,
|
|
|
|
the case for recursion.
|
|
|
|
|
|
|
|
@retval Whether EOF reached before comment is closed.
|
|
|
|
*/
|
|
|
|
bool consume_comment(Lex_input_stream *lip, int remaining_recursions_permitted)
|
|
|
|
{
|
|
|
|
reg1 uchar c;
|
|
|
|
while (! lip->eof())
|
|
|
|
{
|
|
|
|
c= lip->yyGet();
|
|
|
|
|
|
|
|
if (remaining_recursions_permitted > 0)
|
|
|
|
{
|
|
|
|
if ((c == '/') && (lip->yyPeek() == '*'))
|
|
|
|
{
|
|
|
|
lip->yySkip(); /* Eat asterisk */
|
|
|
|
consume_comment(lip, remaining_recursions_permitted-1);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (c == '*')
|
|
|
|
{
|
|
|
|
if (lip->yyPeek() == '/')
|
|
|
|
{
|
|
|
|
lip->yySkip(); /* Eat slash */
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (c == '\n')
|
|
|
|
lip->yylineno++;
|
|
|
|
}
|
|
|
|
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2003-11-03 13:01:59 +01:00
|
|
|
/*
|
2006-03-10 01:44:08 +01:00
|
|
|
MYSQLlex remember the following states from the following MYSQLlex()
|
2003-11-03 13:01:59 +01:00
|
|
|
|
|
|
|
- MY_LEX_EOQ Found end of query
|
|
|
|
- MY_LEX_OPERATOR_OR_IDENT Last state was an ident, text or number
|
|
|
|
(which can't be followed by a signed number)
|
|
|
|
*/
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2006-03-10 01:44:08 +01:00
|
|
|
int MYSQLlex(void *arg, void *yythd)
|
2009-11-02 17:31:00 +01:00
|
|
|
{
|
|
|
|
THD *thd= (THD *)yythd;
|
|
|
|
Lex_input_stream *lip= & thd->m_parser_state->m_lip;
|
|
|
|
YYSTYPE *yylval=(YYSTYPE*) arg;
|
|
|
|
int token;
|
|
|
|
|
|
|
|
if (lip->lookahead_token >= 0)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
The next token was already parsed in advance,
|
|
|
|
return it.
|
|
|
|
*/
|
|
|
|
token= lip->lookahead_token;
|
|
|
|
lip->lookahead_token= -1;
|
|
|
|
*yylval= *(lip->lookahead_yylval);
|
|
|
|
lip->lookahead_yylval= NULL;
|
|
|
|
return token;
|
|
|
|
}
|
|
|
|
|
|
|
|
token= lex_one_token(arg, yythd);
|
|
|
|
|
|
|
|
switch(token) {
|
|
|
|
case WITH:
|
|
|
|
/*
|
|
|
|
Parsing 'WITH' 'ROLLUP' or 'WITH' 'CUBE' requires 2 look ups,
|
|
|
|
which makes the grammar LALR(2).
|
|
|
|
Replace by a single 'WITH_ROLLUP' or 'WITH_CUBE' token,
|
|
|
|
to transform the grammar into a LALR(1) grammar,
|
|
|
|
which sql_yacc.yy can process.
|
|
|
|
*/
|
|
|
|
token= lex_one_token(arg, yythd);
|
|
|
|
switch(token) {
|
|
|
|
case CUBE_SYM:
|
|
|
|
return WITH_CUBE_SYM;
|
|
|
|
case ROLLUP_SYM:
|
|
|
|
return WITH_ROLLUP_SYM;
|
|
|
|
default:
|
|
|
|
/*
|
|
|
|
Save the token following 'WITH'
|
|
|
|
*/
|
|
|
|
lip->lookahead_yylval= lip->yylval;
|
|
|
|
lip->yylval= NULL;
|
|
|
|
lip->lookahead_token= token;
|
|
|
|
return WITH;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return token;
|
|
|
|
}
|
|
|
|
|
|
|
|
int lex_one_token(void *arg, void *yythd)
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2009-06-17 16:56:44 +02:00
|
|
|
reg1 uchar c= 0;
|
2007-08-30 20:57:05 +02:00
|
|
|
bool comment_closed;
|
2003-11-03 13:01:59 +01:00
|
|
|
int tokval, result_state;
|
2000-07-31 21:29:14 +02:00
|
|
|
uint length;
|
2003-11-20 21:06:25 +01:00
|
|
|
enum my_lex_states state;
|
2007-04-26 05:38:12 +02:00
|
|
|
THD *thd= (THD *)yythd;
|
2008-07-14 23:41:30 +02:00
|
|
|
Lex_input_stream *lip= & thd->m_parser_state->m_lip;
|
2007-04-26 05:38:12 +02:00
|
|
|
LEX *lex= thd->lex;
|
2000-07-31 21:29:14 +02:00
|
|
|
YYSTYPE *yylval=(YYSTYPE*) arg;
|
2007-04-26 05:38:12 +02:00
|
|
|
CHARSET_INFO *cs= thd->charset();
|
2003-03-14 15:08:12 +01:00
|
|
|
uchar *state_map= cs->state_map;
|
|
|
|
uchar *ident_map= cs->ident_map;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2007-04-26 05:38:12 +02:00
|
|
|
lip->yylval=yylval; // The global state
|
2005-08-25 15:34:34 +02:00
|
|
|
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
lip->start_token();
|
2007-04-26 05:38:12 +02:00
|
|
|
state=lip->next_state;
|
|
|
|
lip->next_state=MY_LEX_OPERATOR_OR_IDENT;
|
2000-07-31 21:29:14 +02:00
|
|
|
for (;;)
|
|
|
|
{
|
2002-12-02 16:52:22 +01:00
|
|
|
switch (state) {
|
2003-03-14 15:08:12 +01:00
|
|
|
case MY_LEX_OPERATOR_OR_IDENT: // Next is operator or keyword
|
|
|
|
case MY_LEX_START: // Start of token
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
// Skip starting whitespace
|
|
|
|
while(state_map[c= lip->yyPeek()] == MY_LEX_SKIP)
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
|
|
|
if (c == '\n')
|
2007-04-26 05:38:12 +02:00
|
|
|
lip->yylineno++;
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
|
|
|
|
lip->yySkip();
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
|
|
|
|
/* Start of real token */
|
|
|
|
lip->restart_token();
|
|
|
|
c= lip->yyGet();
|
2003-03-14 15:08:12 +01:00
|
|
|
state= (enum my_lex_states) state_map[c];
|
2000-07-31 21:29:14 +02:00
|
|
|
break;
|
2003-03-14 15:08:12 +01:00
|
|
|
case MY_LEX_ESCAPE:
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
if (lip->yyGet() == 'N')
|
2000-07-31 21:29:14 +02:00
|
|
|
{ // Allow \N as shortcut for NULL
|
|
|
|
yylval->lex_str.str=(char*) "\\N";
|
|
|
|
yylval->lex_str.length=2;
|
|
|
|
return NULL_SYM;
|
|
|
|
}
|
2003-03-14 15:08:12 +01:00
|
|
|
case MY_LEX_CHAR: // Unknown or single char token
|
|
|
|
case MY_LEX_SKIP: // This should not happen
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
if (c == '-' && lip->yyPeek() == '-' &&
|
|
|
|
(my_isspace(cs,lip->yyPeekn(1)) ||
|
|
|
|
my_iscntrl(cs,lip->yyPeekn(1))))
|
2003-07-20 12:26:18 +02:00
|
|
|
{
|
|
|
|
state=MY_LEX_COMMENT;
|
|
|
|
break;
|
|
|
|
}
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
if (c != ')')
|
2007-04-26 05:38:12 +02:00
|
|
|
lip->next_state= MY_LEX_START; // Allow signed numbers
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
if (c == ',')
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
Warning:
|
|
|
|
This is a work around, to make the "remember_name" rule in
|
|
|
|
sql/sql_yacc.yy work properly.
|
|
|
|
The problem is that, when parsing "select expr1, expr2",
|
|
|
|
the code generated by bison executes the *pre* action
|
|
|
|
remember_name (see select_item) *before* actually parsing the
|
|
|
|
first token of expr2.
|
|
|
|
*/
|
|
|
|
lip->restart_token();
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
Check for a placeholder: it should not precede a possible identifier
|
|
|
|
because of binlogging: when a placeholder is replaced with
|
|
|
|
its value in a query for the binlog, the query must stay
|
|
|
|
grammatically correct.
|
|
|
|
*/
|
|
|
|
if (c == '?' && lip->stmt_prepare_mode && !ident_map[lip->yyPeek()])
|
2005-07-14 22:01:49 +02:00
|
|
|
return(PARAM_MARKER);
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
}
|
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
return((int) c);
|
|
|
|
|
2003-03-20 19:01:03 +01:00
|
|
|
case MY_LEX_IDENT_OR_NCHAR:
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
if (lip->yyPeek() != '\'')
|
|
|
|
{
|
2003-03-20 19:01:03 +01:00
|
|
|
state= MY_LEX_IDENT;
|
|
|
|
break;
|
|
|
|
}
|
2006-07-31 09:47:01 +02:00
|
|
|
/* Found N'string' */
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
lip->yySkip(); // Skip '
|
|
|
|
if (!(yylval->lex_str.str = get_text(lip, 2, 1)))
|
2003-03-20 19:01:03 +01:00
|
|
|
{
|
2006-07-31 09:47:01 +02:00
|
|
|
state= MY_LEX_CHAR; // Read char by char
|
|
|
|
break;
|
2003-03-20 19:01:03 +01:00
|
|
|
}
|
2007-04-26 05:38:12 +02:00
|
|
|
yylval->lex_str.length= lip->yytoklen;
|
2007-08-03 12:25:23 +02:00
|
|
|
lex->text_string_is_7bit= (lip->tok_bitmap & 0x80) ? 0 : 1;
|
2006-07-31 09:47:01 +02:00
|
|
|
return(NCHAR_STRING);
|
2003-03-20 19:01:03 +01:00
|
|
|
|
2003-03-14 15:08:12 +01:00
|
|
|
case MY_LEX_IDENT_OR_HEX:
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
if (lip->yyPeek() == '\'')
|
2001-07-04 08:39:58 +02:00
|
|
|
{ // Found x'hex-number'
|
2003-03-14 15:08:12 +01:00
|
|
|
state= MY_LEX_HEX_NUMBER;
|
2001-07-04 08:39:58 +02:00
|
|
|
break;
|
|
|
|
}
|
2004-12-17 15:06:05 +01:00
|
|
|
case MY_LEX_IDENT_OR_BIN:
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
if (lip->yyPeek() == '\'')
|
2004-12-17 15:06:05 +01:00
|
|
|
{ // Found b'bin-number'
|
|
|
|
state= MY_LEX_BIN_NUMBER;
|
|
|
|
break;
|
|
|
|
}
|
2003-03-14 15:08:12 +01:00
|
|
|
case MY_LEX_IDENT:
|
2007-03-27 19:09:56 +02:00
|
|
|
const char *start;
|
2000-07-31 21:29:14 +02:00
|
|
|
#if defined(USE_MB) && defined(USE_MB_IDENT)
|
2003-03-14 15:08:12 +01:00
|
|
|
if (use_mb(cs))
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2003-11-03 13:01:59 +01:00
|
|
|
result_state= IDENT_QUOTED;
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
if (my_mbcharlen(cs, lip->yyGetLast()) > 1)
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
int l = my_ismbchar(cs,
|
|
|
|
lip->get_ptr() -1,
|
|
|
|
lip->get_end_of_query());
|
2000-07-31 21:29:14 +02:00
|
|
|
if (l == 0) {
|
2003-03-14 15:08:12 +01:00
|
|
|
state = MY_LEX_CHAR;
|
2000-07-31 21:29:14 +02:00
|
|
|
continue;
|
|
|
|
}
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
lip->skip_binary(l - 1);
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
while (ident_map[c=lip->yyGet()])
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2003-04-01 12:52:09 +02:00
|
|
|
if (my_mbcharlen(cs, c) > 1)
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
|
|
|
int l;
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
if ((l = my_ismbchar(cs,
|
|
|
|
lip->get_ptr() -1,
|
|
|
|
lip->get_end_of_query())) == 0)
|
2000-07-31 21:29:14 +02:00
|
|
|
break;
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
lip->skip_binary(l-1);
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
#endif
|
2003-11-03 13:01:59 +01:00
|
|
|
{
|
2009-06-17 16:56:44 +02:00
|
|
|
for (result_state= c; ident_map[c= lip->yyGet()]; result_state|= c) ;
|
2004-06-10 16:10:21 +02:00
|
|
|
/* If there were non-ASCII characters, mark that we must convert */
|
|
|
|
result_state= result_state & 0x80 ? IDENT_QUOTED : IDENT;
|
2003-11-03 13:01:59 +01:00
|
|
|
}
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
length= lip->yyLength();
|
|
|
|
start= lip->get_ptr();
|
2007-04-26 05:38:12 +02:00
|
|
|
if (lip->ignore_space)
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2004-10-14 17:03:46 +02:00
|
|
|
/*
|
|
|
|
If we find a space then this can't be an identifier. We notice this
|
|
|
|
below by checking start != lex->ptr.
|
|
|
|
*/
|
2009-06-17 16:56:44 +02:00
|
|
|
for (; state_map[c] == MY_LEX_SKIP ; c= lip->yyGet()) ;
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
if (start == lip->get_ptr() && c == '.' && ident_map[lip->yyPeek()])
|
2007-04-26 05:38:12 +02:00
|
|
|
lip->next_state=MY_LEX_IDENT_SEP;
|
2000-07-31 21:29:14 +02:00
|
|
|
else
|
|
|
|
{ // '(' must follow directly if function
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
lip->yyUnget();
|
|
|
|
if ((tokval = find_keyword(lip, length, c == '(')))
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2007-04-26 05:38:12 +02:00
|
|
|
lip->next_state= MY_LEX_START; // Allow signed numbers
|
2000-07-31 21:29:14 +02:00
|
|
|
return(tokval); // Was keyword
|
|
|
|
}
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
lip->yySkip(); // next state does a unget
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
Bug#21513 (SP having body starting with quoted label rendered unusable)
Before this fix, the parser would sometime change where a token starts by
altering Lex_input_string::tok_start, which later confused the code in
sql_yacc.yy that needs to capture the source code of a SQL statement,
like to represent the body of a stored procedure.
This line of code in sql_lex.cc :
case MY_LEX_USER_VARIABLE_DELIMITER:
lip->tok_start= lip->ptr; // Skip first `
would <skip the first back quote> ... and cause the bug reported.
In general, the responsibility of sql_lex.cc is to *find* where token are
in the SQL text, but is *not* to make up fake or incomplete tokens.
With a quoted label like `my_label`, the token starts on the first quote.
Extracting the token value should not change that (it did).
With this fix, the lexical analysis has been cleaned up to not change
lip->tok_start (in the case found for this bug).
The functions get_token() and get_quoted_token() now have an extra
parameters, used when some characters from the beginning of the token need
to be skipped when extracting a token value, like when extracting 'AB' from
'0xAB', for example, for a HEX_NUM token.
This exposed a bad assumption in Item_hex_string and Item_bin_string,
which has been fixed:
The assumption was that the string given, 'AB', was in fact preceded in
memory by '0x', which might be false (it can be preceded by "x'" and
followed by "'" -- or not be preceded by valid memory at all)
If a name is needed for Item_hex_string or Item_bin_string, the name is
taken from the original and true source code ('0xAB'), and assigned in
the select_item rule, instead of relying on assumptions related to how
memory is used.
2007-04-28 01:14:25 +02:00
|
|
|
yylval->lex_str=get_token(lip, 0, length);
|
2002-06-20 15:47:55 +02:00
|
|
|
|
Patch for the following bugs:
- BUG#11986: Stored routines and triggers can fail if the code
has a non-ascii symbol
- BUG#16291: mysqldump corrupts string-constants with non-ascii-chars
- BUG#19443: INFORMATION_SCHEMA does not support charsets properly
- BUG#21249: Character set of SP-var can be ignored
- BUG#25212: Character set of string constant is ignored (stored routines)
- BUG#25221: Character set of string constant is ignored (triggers)
There were a few general problems that caused these bugs:
1. Character set information of the original (definition) query for views,
triggers, stored routines and events was lost.
2. mysqldump output query in client character set, which can be
inappropriate to encode definition-query.
3. INFORMATION_SCHEMA used strings with mixed encodings to display object
definition;
1. No query-definition-character set.
In order to compile query into execution code, some extra data (such as
environment variables or the database character set) is used. The problem
here was that this context was not preserved. So, on the next load it can
differ from the original one, thus the result will be different.
The context contains the following data:
- client character set;
- connection collation (character set and collation);
- collation of the owner database;
The fix is to store this context and use it each time we parse (compile)
and execute the object (stored routine, trigger, ...).
2. Wrong mysqldump-output.
The original query can contain several encodings (by means of character set
introducers). The problem here was that we tried to convert original query
to the mysqldump-client character set.
Moreover, we stored queries in different character sets for different
objects (views, for one, used UTF8, triggers used original character set).
The solution is
- to store definition queries in the original character set;
- to change SHOW CREATE statement to output definition query in the
binary character set (i.e. without any conversion);
- introduce SHOW CREATE TRIGGER statement;
- to dump special statements to switch the context to the original one
before dumping and restore it afterwards.
Note, in order to preserve the database collation at the creation time,
additional ALTER DATABASE might be used (to temporary switch the database
collation back to the original value). In this case, ALTER DATABASE
privilege will be required. This is a backward-incompatible change.
3. INFORMATION_SCHEMA showed non-UTF8 strings
The fix is to generate UTF8-query during the parsing, store it in the object
and show it in the INFORMATION_SCHEMA.
Basically, the idea is to create a copy of the original query convert it to
UTF8. Character set introducers are removed and all text literals are
converted to UTF8.
This UTF8 query is intended to provide user-readable output. It must not be
used to recreate the object. Specialized SHOW CREATE statements should be
used for this.
The reason for this limitation is the following: the original query can
contain symbols from several character sets (by means of character set
introducers).
Example:
- original query:
CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1;
- UTF8 query (for INFORMATION_SCHEMA):
CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 19:34:54 +02:00
|
|
|
/*
|
2002-06-20 15:47:55 +02:00
|
|
|
Note: "SELECT _bla AS 'alias'"
|
|
|
|
_bla should be considered as a IDENT if charset haven't been found.
|
Patch for the following bugs:
- BUG#11986: Stored routines and triggers can fail if the code
has a non-ascii symbol
- BUG#16291: mysqldump corrupts string-constants with non-ascii-chars
- BUG#19443: INFORMATION_SCHEMA does not support charsets properly
- BUG#21249: Character set of SP-var can be ignored
- BUG#25212: Character set of string constant is ignored (stored routines)
- BUG#25221: Character set of string constant is ignored (triggers)
There were a few general problems that caused these bugs:
1. Character set information of the original (definition) query for views,
triggers, stored routines and events was lost.
2. mysqldump output query in client character set, which can be
inappropriate to encode definition-query.
3. INFORMATION_SCHEMA used strings with mixed encodings to display object
definition;
1. No query-definition-character set.
In order to compile query into execution code, some extra data (such as
environment variables or the database character set) is used. The problem
here was that this context was not preserved. So, on the next load it can
differ from the original one, thus the result will be different.
The context contains the following data:
- client character set;
- connection collation (character set and collation);
- collation of the owner database;
The fix is to store this context and use it each time we parse (compile)
and execute the object (stored routine, trigger, ...).
2. Wrong mysqldump-output.
The original query can contain several encodings (by means of character set
introducers). The problem here was that we tried to convert original query
to the mysqldump-client character set.
Moreover, we stored queries in different character sets for different
objects (views, for one, used UTF8, triggers used original character set).
The solution is
- to store definition queries in the original character set;
- to change SHOW CREATE statement to output definition query in the
binary character set (i.e. without any conversion);
- introduce SHOW CREATE TRIGGER statement;
- to dump special statements to switch the context to the original one
before dumping and restore it afterwards.
Note, in order to preserve the database collation at the creation time,
additional ALTER DATABASE might be used (to temporary switch the database
collation back to the original value). In this case, ALTER DATABASE
privilege will be required. This is a backward-incompatible change.
3. INFORMATION_SCHEMA showed non-UTF8 strings
The fix is to generate UTF8-query during the parsing, store it in the object
and show it in the INFORMATION_SCHEMA.
Basically, the idea is to create a copy of the original query convert it to
UTF8. Character set introducers are removed and all text literals are
converted to UTF8.
This UTF8 query is intended to provide user-readable output. It must not be
used to recreate the object. Specialized SHOW CREATE statements should be
used for this.
The reason for this limitation is the following: the original query can
contain symbols from several character sets (by means of character set
introducers).
Example:
- original query:
CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1;
- UTF8 query (for INFORMATION_SCHEMA):
CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 19:34:54 +02:00
|
|
|
So we don't use MYF(MY_WME) with get_charset_by_csname to avoid
|
2002-06-20 15:47:55 +02:00
|
|
|
producing an error.
|
|
|
|
*/
|
|
|
|
|
Patch for the following bugs:
- BUG#11986: Stored routines and triggers can fail if the code
has a non-ascii symbol
- BUG#16291: mysqldump corrupts string-constants with non-ascii-chars
- BUG#19443: INFORMATION_SCHEMA does not support charsets properly
- BUG#21249: Character set of SP-var can be ignored
- BUG#25212: Character set of string constant is ignored (stored routines)
- BUG#25221: Character set of string constant is ignored (triggers)
There were a few general problems that caused these bugs:
1. Character set information of the original (definition) query for views,
triggers, stored routines and events was lost.
2. mysqldump output query in client character set, which can be
inappropriate to encode definition-query.
3. INFORMATION_SCHEMA used strings with mixed encodings to display object
definition;
1. No query-definition-character set.
In order to compile query into execution code, some extra data (such as
environment variables or the database character set) is used. The problem
here was that this context was not preserved. So, on the next load it can
differ from the original one, thus the result will be different.
The context contains the following data:
- client character set;
- connection collation (character set and collation);
- collation of the owner database;
The fix is to store this context and use it each time we parse (compile)
and execute the object (stored routine, trigger, ...).
2. Wrong mysqldump-output.
The original query can contain several encodings (by means of character set
introducers). The problem here was that we tried to convert original query
to the mysqldump-client character set.
Moreover, we stored queries in different character sets for different
objects (views, for one, used UTF8, triggers used original character set).
The solution is
- to store definition queries in the original character set;
- to change SHOW CREATE statement to output definition query in the
binary character set (i.e. without any conversion);
- introduce SHOW CREATE TRIGGER statement;
- to dump special statements to switch the context to the original one
before dumping and restore it afterwards.
Note, in order to preserve the database collation at the creation time,
additional ALTER DATABASE might be used (to temporary switch the database
collation back to the original value). In this case, ALTER DATABASE
privilege will be required. This is a backward-incompatible change.
3. INFORMATION_SCHEMA showed non-UTF8 strings
The fix is to generate UTF8-query during the parsing, store it in the object
and show it in the INFORMATION_SCHEMA.
Basically, the idea is to create a copy of the original query convert it to
UTF8. Character set introducers are removed and all text literals are
converted to UTF8.
This UTF8 query is intended to provide user-readable output. It must not be
used to recreate the object. Specialized SHOW CREATE statements should be
used for this.
The reason for this limitation is the following: the original query can
contain symbols from several character sets (by means of character set
introducers).
Example:
- original query:
CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1;
- UTF8 query (for INFORMATION_SCHEMA):
CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 19:34:54 +02:00
|
|
|
if (yylval->lex_str.str[0] == '_')
|
|
|
|
{
|
|
|
|
CHARSET_INFO *cs= get_charset_by_csname(yylval->lex_str.str + 1,
|
|
|
|
MY_CS_PRIMARY, MYF(0));
|
|
|
|
if (cs)
|
|
|
|
{
|
|
|
|
yylval->charset= cs;
|
|
|
|
lip->m_underscore_cs= cs;
|
|
|
|
|
|
|
|
lip->body_utf8_append(lip->m_cpp_text_start,
|
|
|
|
lip->get_cpp_tok_start() + length);
|
|
|
|
return(UNDERSCORE_CHARSET);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
lip->body_utf8_append(lip->m_cpp_text_start);
|
|
|
|
|
|
|
|
lip->body_utf8_append_literal(thd, &yylval->lex_str, cs,
|
|
|
|
lip->m_cpp_text_end);
|
|
|
|
|
2003-11-03 13:01:59 +01:00
|
|
|
return(result_state); // IDENT or IDENT_QUOTED
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2003-03-14 15:08:12 +01:00
|
|
|
case MY_LEX_IDENT_SEP: // Found ident and now '.'
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
yylval->lex_str.str= (char*) lip->get_ptr();
|
|
|
|
yylval->lex_str.length= 1;
|
|
|
|
c= lip->yyGet(); // should be '.'
|
2007-04-26 05:38:12 +02:00
|
|
|
lip->next_state= MY_LEX_IDENT_START;// Next is an ident (not a keyword)
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
if (!ident_map[lip->yyPeek()]) // Probably ` or "
|
2007-04-26 05:38:12 +02:00
|
|
|
lip->next_state= MY_LEX_START;
|
2000-07-31 21:29:14 +02:00
|
|
|
return((int) c);
|
|
|
|
|
2003-03-14 15:08:12 +01:00
|
|
|
case MY_LEX_NUMBER_IDENT: // number or ident which num-start
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
if (lip->yyGetLast() == '0')
|
|
|
|
{
|
|
|
|
c= lip->yyGet();
|
|
|
|
if (c == 'x')
|
|
|
|
{
|
|
|
|
while (my_isxdigit(cs,(c = lip->yyGet()))) ;
|
|
|
|
if ((lip->yyLength() >= 3) && !ident_map[c])
|
|
|
|
{
|
|
|
|
/* skip '0x' */
|
|
|
|
yylval->lex_str=get_token(lip, 2, lip->yyLength()-2);
|
|
|
|
return (HEX_NUM);
|
|
|
|
}
|
|
|
|
lip->yyUnget();
|
|
|
|
state= MY_LEX_IDENT_START;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
else if (c == 'b')
|
|
|
|
{
|
2009-06-17 16:56:44 +02:00
|
|
|
while ((c= lip->yyGet()) == '0' || c == '1') ;
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
if ((lip->yyLength() >= 3) && !ident_map[c])
|
|
|
|
{
|
|
|
|
/* Skip '0b' */
|
|
|
|
yylval->lex_str= get_token(lip, 2, lip->yyLength()-2);
|
|
|
|
return (BIN_NUM);
|
|
|
|
}
|
|
|
|
lip->yyUnget();
|
|
|
|
state= MY_LEX_IDENT_START;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
lip->yyUnget();
|
|
|
|
}
|
|
|
|
|
|
|
|
while (my_isdigit(cs, (c = lip->yyGet()))) ;
|
2002-11-25 11:11:16 +01:00
|
|
|
if (!ident_map[c])
|
2000-07-31 21:29:14 +02:00
|
|
|
{ // Can't be identifier
|
2003-03-14 15:08:12 +01:00
|
|
|
state=MY_LEX_INT_OR_REAL;
|
2000-07-31 21:29:14 +02:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (c == 'e' || c == 'E')
|
|
|
|
{
|
2000-10-10 23:48:03 +02:00
|
|
|
// The following test is written this way to allow numbers of type 1e1
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
if (my_isdigit(cs,lip->yyPeek()) ||
|
|
|
|
(c=(lip->yyGet())) == '+' || c == '-')
|
2000-07-31 21:29:14 +02:00
|
|
|
{ // Allow 1E+10
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
if (my_isdigit(cs,lip->yyPeek())) // Number must have digit after sign
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
lip->yySkip();
|
|
|
|
while (my_isdigit(cs,lip->yyGet())) ;
|
|
|
|
yylval->lex_str=get_token(lip, 0, lip->yyLength());
|
2000-07-31 21:29:14 +02:00
|
|
|
return(FLOAT_NUM);
|
|
|
|
}
|
|
|
|
}
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
lip->yyUnget();
|
2004-12-17 15:06:05 +01:00
|
|
|
}
|
2000-07-31 21:29:14 +02:00
|
|
|
// fall through
|
2003-07-06 18:09:57 +02:00
|
|
|
case MY_LEX_IDENT_START: // We come here after '.'
|
2003-11-03 13:01:59 +01:00
|
|
|
result_state= IDENT;
|
2000-07-31 21:29:14 +02:00
|
|
|
#if defined(USE_MB) && defined(USE_MB_IDENT)
|
2003-03-14 15:08:12 +01:00
|
|
|
if (use_mb(cs))
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2003-11-03 13:01:59 +01:00
|
|
|
result_state= IDENT_QUOTED;
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
while (ident_map[c=lip->yyGet()])
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2003-04-01 12:52:09 +02:00
|
|
|
if (my_mbcharlen(cs, c) > 1)
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
|
|
|
int l;
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
if ((l = my_ismbchar(cs,
|
|
|
|
lip->get_ptr() -1,
|
|
|
|
lip->get_end_of_query())) == 0)
|
2000-07-31 21:29:14 +02:00
|
|
|
break;
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
lip->skip_binary(l-1);
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
#endif
|
2004-06-10 16:10:21 +02:00
|
|
|
{
|
2009-06-17 16:56:44 +02:00
|
|
|
for (result_state=0; ident_map[c= lip->yyGet()]; result_state|= c) ;
|
2004-06-10 16:10:21 +02:00
|
|
|
/* If there were non-ASCII characters, mark that we must convert */
|
|
|
|
result_state= result_state & 0x80 ? IDENT_QUOTED : IDENT;
|
|
|
|
}
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
if (c == '.' && ident_map[lip->yyPeek()])
|
2007-04-26 05:38:12 +02:00
|
|
|
lip->next_state=MY_LEX_IDENT_SEP;// Next is '.'
|
2000-07-31 21:29:14 +02:00
|
|
|
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
yylval->lex_str= get_token(lip, 0, lip->yyLength());
|
Patch for the following bugs:
- BUG#11986: Stored routines and triggers can fail if the code
has a non-ascii symbol
- BUG#16291: mysqldump corrupts string-constants with non-ascii-chars
- BUG#19443: INFORMATION_SCHEMA does not support charsets properly
- BUG#21249: Character set of SP-var can be ignored
- BUG#25212: Character set of string constant is ignored (stored routines)
- BUG#25221: Character set of string constant is ignored (triggers)
There were a few general problems that caused these bugs:
1. Character set information of the original (definition) query for views,
triggers, stored routines and events was lost.
2. mysqldump output query in client character set, which can be
inappropriate to encode definition-query.
3. INFORMATION_SCHEMA used strings with mixed encodings to display object
definition;
1. No query-definition-character set.
In order to compile query into execution code, some extra data (such as
environment variables or the database character set) is used. The problem
here was that this context was not preserved. So, on the next load it can
differ from the original one, thus the result will be different.
The context contains the following data:
- client character set;
- connection collation (character set and collation);
- collation of the owner database;
The fix is to store this context and use it each time we parse (compile)
and execute the object (stored routine, trigger, ...).
2. Wrong mysqldump-output.
The original query can contain several encodings (by means of character set
introducers). The problem here was that we tried to convert original query
to the mysqldump-client character set.
Moreover, we stored queries in different character sets for different
objects (views, for one, used UTF8, triggers used original character set).
The solution is
- to store definition queries in the original character set;
- to change SHOW CREATE statement to output definition query in the
binary character set (i.e. without any conversion);
- introduce SHOW CREATE TRIGGER statement;
- to dump special statements to switch the context to the original one
before dumping and restore it afterwards.
Note, in order to preserve the database collation at the creation time,
additional ALTER DATABASE might be used (to temporary switch the database
collation back to the original value). In this case, ALTER DATABASE
privilege will be required. This is a backward-incompatible change.
3. INFORMATION_SCHEMA showed non-UTF8 strings
The fix is to generate UTF8-query during the parsing, store it in the object
and show it in the INFORMATION_SCHEMA.
Basically, the idea is to create a copy of the original query convert it to
UTF8. Character set introducers are removed and all text literals are
converted to UTF8.
This UTF8 query is intended to provide user-readable output. It must not be
used to recreate the object. Specialized SHOW CREATE statements should be
used for this.
The reason for this limitation is the following: the original query can
contain symbols from several character sets (by means of character set
introducers).
Example:
- original query:
CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1;
- UTF8 query (for INFORMATION_SCHEMA):
CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 19:34:54 +02:00
|
|
|
|
|
|
|
lip->body_utf8_append(lip->m_cpp_text_start);
|
|
|
|
|
|
|
|
lip->body_utf8_append_literal(thd, &yylval->lex_str, cs,
|
|
|
|
lip->m_cpp_text_end);
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2003-11-03 13:01:59 +01:00
|
|
|
return(result_state);
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2004-02-17 00:35:17 +01:00
|
|
|
case MY_LEX_USER_VARIABLE_DELIMITER: // Found quote char
|
2003-01-17 15:33:54 +01:00
|
|
|
{
|
2004-02-06 23:22:12 +01:00
|
|
|
uint double_quotes= 0;
|
|
|
|
char quote_char= c; // Used char
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
while ((c=lip->yyGet()))
|
2004-02-13 23:26:27 +01:00
|
|
|
{
|
2006-12-14 23:51:37 +01:00
|
|
|
int var_length;
|
|
|
|
if ((var_length= my_mbcharlen(cs, c)) == 1)
|
2002-12-01 13:59:06 +01:00
|
|
|
{
|
|
|
|
if (c == quote_char)
|
|
|
|
{
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
if (lip->yyPeek() != quote_char)
|
2002-12-01 13:59:06 +01:00
|
|
|
break;
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
c=lip->yyGet();
|
2002-12-01 13:59:06 +01:00
|
|
|
double_quotes++;
|
|
|
|
continue;
|
|
|
|
}
|
2004-02-10 21:47:18 +01:00
|
|
|
}
|
|
|
|
#ifdef USE_MB
|
2009-08-10 20:46:20 +02:00
|
|
|
else if (use_mb(cs))
|
2009-08-08 04:32:01 +02:00
|
|
|
{
|
2009-08-10 20:46:20 +02:00
|
|
|
if ((var_length= my_ismbchar(cs, lip->get_ptr() - 1,
|
|
|
|
lip->get_end_of_query())))
|
|
|
|
lip->skip_binary(var_length-1);
|
2009-08-08 04:32:01 +02:00
|
|
|
}
|
2004-02-10 21:47:18 +01:00
|
|
|
#endif
|
2001-10-30 15:31:35 +01:00
|
|
|
}
|
2004-02-06 23:22:12 +01:00
|
|
|
if (double_quotes)
|
Bug#21513 (SP having body starting with quoted label rendered unusable)
Before this fix, the parser would sometime change where a token starts by
altering Lex_input_string::tok_start, which later confused the code in
sql_yacc.yy that needs to capture the source code of a SQL statement,
like to represent the body of a stored procedure.
This line of code in sql_lex.cc :
case MY_LEX_USER_VARIABLE_DELIMITER:
lip->tok_start= lip->ptr; // Skip first `
would <skip the first back quote> ... and cause the bug reported.
In general, the responsibility of sql_lex.cc is to *find* where token are
in the SQL text, but is *not* to make up fake or incomplete tokens.
With a quoted label like `my_label`, the token starts on the first quote.
Extracting the token value should not change that (it did).
With this fix, the lexical analysis has been cleaned up to not change
lip->tok_start (in the case found for this bug).
The functions get_token() and get_quoted_token() now have an extra
parameters, used when some characters from the beginning of the token need
to be skipped when extracting a token value, like when extracting 'AB' from
'0xAB', for example, for a HEX_NUM token.
This exposed a bad assumption in Item_hex_string and Item_bin_string,
which has been fixed:
The assumption was that the string given, 'AB', was in fact preceded in
memory by '0x', which might be false (it can be preceded by "x'" and
followed by "'" -- or not be preceded by valid memory at all)
If a name is needed for Item_hex_string or Item_bin_string, the name is
taken from the original and true source code ('0xAB'), and assigned in
the select_item rule, instead of relying on assumptions related to how
memory is used.
2007-04-28 01:14:25 +02:00
|
|
|
yylval->lex_str=get_quoted_token(lip, 1,
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
lip->yyLength() - double_quotes -1,
|
2004-02-06 23:22:12 +01:00
|
|
|
quote_char);
|
|
|
|
else
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
yylval->lex_str=get_token(lip, 1, lip->yyLength() -1);
|
2004-02-06 23:22:12 +01:00
|
|
|
if (c == quote_char)
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
lip->yySkip(); // Skip end `
|
2007-04-26 05:38:12 +02:00
|
|
|
lip->next_state= MY_LEX_START;
|
Patch for the following bugs:
- BUG#11986: Stored routines and triggers can fail if the code
has a non-ascii symbol
- BUG#16291: mysqldump corrupts string-constants with non-ascii-chars
- BUG#19443: INFORMATION_SCHEMA does not support charsets properly
- BUG#21249: Character set of SP-var can be ignored
- BUG#25212: Character set of string constant is ignored (stored routines)
- BUG#25221: Character set of string constant is ignored (triggers)
There were a few general problems that caused these bugs:
1. Character set information of the original (definition) query for views,
triggers, stored routines and events was lost.
2. mysqldump output query in client character set, which can be
inappropriate to encode definition-query.
3. INFORMATION_SCHEMA used strings with mixed encodings to display object
definition;
1. No query-definition-character set.
In order to compile query into execution code, some extra data (such as
environment variables or the database character set) is used. The problem
here was that this context was not preserved. So, on the next load it can
differ from the original one, thus the result will be different.
The context contains the following data:
- client character set;
- connection collation (character set and collation);
- collation of the owner database;
The fix is to store this context and use it each time we parse (compile)
and execute the object (stored routine, trigger, ...).
2. Wrong mysqldump-output.
The original query can contain several encodings (by means of character set
introducers). The problem here was that we tried to convert original query
to the mysqldump-client character set.
Moreover, we stored queries in different character sets for different
objects (views, for one, used UTF8, triggers used original character set).
The solution is
- to store definition queries in the original character set;
- to change SHOW CREATE statement to output definition query in the
binary character set (i.e. without any conversion);
- introduce SHOW CREATE TRIGGER statement;
- to dump special statements to switch the context to the original one
before dumping and restore it afterwards.
Note, in order to preserve the database collation at the creation time,
additional ALTER DATABASE might be used (to temporary switch the database
collation back to the original value). In this case, ALTER DATABASE
privilege will be required. This is a backward-incompatible change.
3. INFORMATION_SCHEMA showed non-UTF8 strings
The fix is to generate UTF8-query during the parsing, store it in the object
and show it in the INFORMATION_SCHEMA.
Basically, the idea is to create a copy of the original query convert it to
UTF8. Character set introducers are removed and all text literals are
converted to UTF8.
This UTF8 query is intended to provide user-readable output. It must not be
used to recreate the object. Specialized SHOW CREATE statements should be
used for this.
The reason for this limitation is the following: the original query can
contain symbols from several character sets (by means of character set
introducers).
Example:
- original query:
CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1;
- UTF8 query (for INFORMATION_SCHEMA):
CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 19:34:54 +02:00
|
|
|
|
|
|
|
lip->body_utf8_append(lip->m_cpp_text_start);
|
|
|
|
|
|
|
|
lip->body_utf8_append_literal(thd, &yylval->lex_str, cs,
|
|
|
|
lip->m_cpp_text_end);
|
|
|
|
|
2003-11-03 13:01:59 +01:00
|
|
|
return(IDENT_QUOTED);
|
2003-01-17 15:33:54 +01:00
|
|
|
}
|
Bug#21513 (SP having body starting with quoted label rendered unusable)
Before this fix, the parser would sometime change where a token starts by
altering Lex_input_string::tok_start, which later confused the code in
sql_yacc.yy that needs to capture the source code of a SQL statement,
like to represent the body of a stored procedure.
This line of code in sql_lex.cc :
case MY_LEX_USER_VARIABLE_DELIMITER:
lip->tok_start= lip->ptr; // Skip first `
would <skip the first back quote> ... and cause the bug reported.
In general, the responsibility of sql_lex.cc is to *find* where token are
in the SQL text, but is *not* to make up fake or incomplete tokens.
With a quoted label like `my_label`, the token starts on the first quote.
Extracting the token value should not change that (it did).
With this fix, the lexical analysis has been cleaned up to not change
lip->tok_start (in the case found for this bug).
The functions get_token() and get_quoted_token() now have an extra
parameters, used when some characters from the beginning of the token need
to be skipped when extracting a token value, like when extracting 'AB' from
'0xAB', for example, for a HEX_NUM token.
This exposed a bad assumption in Item_hex_string and Item_bin_string,
which has been fixed:
The assumption was that the string given, 'AB', was in fact preceded in
memory by '0x', which might be false (it can be preceded by "x'" and
followed by "'" -- or not be preceded by valid memory at all)
If a name is needed for Item_hex_string or Item_bin_string, the name is
taken from the original and true source code ('0xAB'), and assigned in
the select_item rule, instead of relying on assumptions related to how
memory is used.
2007-04-28 01:14:25 +02:00
|
|
|
case MY_LEX_INT_OR_REAL: // Complete int or incomplete real
|
2000-07-31 21:29:14 +02:00
|
|
|
if (c != '.')
|
|
|
|
{ // Found complete integer number.
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
yylval->lex_str=get_token(lip, 0, lip->yyLength());
|
2009-02-13 17:41:47 +01:00
|
|
|
return int_token(yylval->lex_str.str, (uint) yylval->lex_str.length);
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
|
|
|
// fall through
|
2003-03-14 15:08:12 +01:00
|
|
|
case MY_LEX_REAL: // Incomplete real number
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
while (my_isdigit(cs,c = lip->yyGet())) ;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
if (c == 'e' || c == 'E')
|
|
|
|
{
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
c = lip->yyGet();
|
2001-06-28 14:24:28 +02:00
|
|
|
if (c == '-' || c == '+')
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
c = lip->yyGet(); // Skip sign
|
2003-03-14 15:08:12 +01:00
|
|
|
if (!my_isdigit(cs,c))
|
2000-07-31 21:29:14 +02:00
|
|
|
{ // No digit after sign
|
2003-03-14 15:08:12 +01:00
|
|
|
state= MY_LEX_CHAR;
|
2000-07-31 21:29:14 +02:00
|
|
|
break;
|
|
|
|
}
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
while (my_isdigit(cs,lip->yyGet())) ;
|
|
|
|
yylval->lex_str=get_token(lip, 0, lip->yyLength());
|
2000-07-31 21:29:14 +02:00
|
|
|
return(FLOAT_NUM);
|
|
|
|
}
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
yylval->lex_str=get_token(lip, 0, lip->yyLength());
|
2005-02-08 23:50:45 +01:00
|
|
|
return(DECIMAL_NUM);
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2003-03-14 15:08:12 +01:00
|
|
|
case MY_LEX_HEX_NUMBER: // Found x'hexstring'
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
lip->yySkip(); // Accept opening '
|
|
|
|
while (my_isxdigit(cs, (c= lip->yyGet()))) ;
|
|
|
|
if (c != '\'')
|
|
|
|
return(ABORT_SYM); // Illegal hex constant
|
|
|
|
lip->yySkip(); // Accept closing '
|
|
|
|
length= lip->yyLength(); // Length of hexnum+3
|
|
|
|
if ((length % 2) == 0)
|
|
|
|
return(ABORT_SYM); // odd number of hex digits
|
Bug#21513 (SP having body starting with quoted label rendered unusable)
Before this fix, the parser would sometime change where a token starts by
altering Lex_input_string::tok_start, which later confused the code in
sql_yacc.yy that needs to capture the source code of a SQL statement,
like to represent the body of a stored procedure.
This line of code in sql_lex.cc :
case MY_LEX_USER_VARIABLE_DELIMITER:
lip->tok_start= lip->ptr; // Skip first `
would <skip the first back quote> ... and cause the bug reported.
In general, the responsibility of sql_lex.cc is to *find* where token are
in the SQL text, but is *not* to make up fake or incomplete tokens.
With a quoted label like `my_label`, the token starts on the first quote.
Extracting the token value should not change that (it did).
With this fix, the lexical analysis has been cleaned up to not change
lip->tok_start (in the case found for this bug).
The functions get_token() and get_quoted_token() now have an extra
parameters, used when some characters from the beginning of the token need
to be skipped when extracting a token value, like when extracting 'AB' from
'0xAB', for example, for a HEX_NUM token.
This exposed a bad assumption in Item_hex_string and Item_bin_string,
which has been fixed:
The assumption was that the string given, 'AB', was in fact preceded in
memory by '0x', which might be false (it can be preceded by "x'" and
followed by "'" -- or not be preceded by valid memory at all)
If a name is needed for Item_hex_string or Item_bin_string, the name is
taken from the original and true source code ('0xAB'), and assigned in
the select_item rule, instead of relying on assumptions related to how
memory is used.
2007-04-28 01:14:25 +02:00
|
|
|
yylval->lex_str=get_token(lip,
|
|
|
|
2, // skip x'
|
|
|
|
length-3); // don't count x' and last '
|
2001-07-04 08:39:58 +02:00
|
|
|
return (HEX_NUM);
|
|
|
|
|
2004-12-17 15:06:05 +01:00
|
|
|
case MY_LEX_BIN_NUMBER: // Found b'bin-string'
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
lip->yySkip(); // Accept opening '
|
2009-06-17 16:56:44 +02:00
|
|
|
while ((c= lip->yyGet()) == '0' || c == '1') ;
|
2004-12-17 15:06:05 +01:00
|
|
|
if (c != '\'')
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
return(ABORT_SYM); // Illegal hex constant
|
|
|
|
lip->yySkip(); // Accept closing '
|
|
|
|
length= lip->yyLength(); // Length of bin-num + 3
|
Bug#21513 (SP having body starting with quoted label rendered unusable)
Before this fix, the parser would sometime change where a token starts by
altering Lex_input_string::tok_start, which later confused the code in
sql_yacc.yy that needs to capture the source code of a SQL statement,
like to represent the body of a stored procedure.
This line of code in sql_lex.cc :
case MY_LEX_USER_VARIABLE_DELIMITER:
lip->tok_start= lip->ptr; // Skip first `
would <skip the first back quote> ... and cause the bug reported.
In general, the responsibility of sql_lex.cc is to *find* where token are
in the SQL text, but is *not* to make up fake or incomplete tokens.
With a quoted label like `my_label`, the token starts on the first quote.
Extracting the token value should not change that (it did).
With this fix, the lexical analysis has been cleaned up to not change
lip->tok_start (in the case found for this bug).
The functions get_token() and get_quoted_token() now have an extra
parameters, used when some characters from the beginning of the token need
to be skipped when extracting a token value, like when extracting 'AB' from
'0xAB', for example, for a HEX_NUM token.
This exposed a bad assumption in Item_hex_string and Item_bin_string,
which has been fixed:
The assumption was that the string given, 'AB', was in fact preceded in
memory by '0x', which might be false (it can be preceded by "x'" and
followed by "'" -- or not be preceded by valid memory at all)
If a name is needed for Item_hex_string or Item_bin_string, the name is
taken from the original and true source code ('0xAB'), and assigned in
the select_item rule, instead of relying on assumptions related to how
memory is used.
2007-04-28 01:14:25 +02:00
|
|
|
yylval->lex_str= get_token(lip,
|
|
|
|
2, // skip b'
|
|
|
|
length-3); // don't count b' and last '
|
|
|
|
return (BIN_NUM);
|
2004-12-17 15:06:05 +01:00
|
|
|
|
2003-03-14 15:08:12 +01:00
|
|
|
case MY_LEX_CMP_OP: // Incomplete comparison operator
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
if (state_map[lip->yyPeek()] == MY_LEX_CMP_OP ||
|
|
|
|
state_map[lip->yyPeek()] == MY_LEX_LONG_CMP_OP)
|
|
|
|
lip->yySkip();
|
|
|
|
if ((tokval = find_keyword(lip, lip->yyLength() + 1, 0)))
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2007-04-26 05:38:12 +02:00
|
|
|
lip->next_state= MY_LEX_START; // Allow signed numbers
|
2000-07-31 21:29:14 +02:00
|
|
|
return(tokval);
|
|
|
|
}
|
2003-03-14 15:08:12 +01:00
|
|
|
state = MY_LEX_CHAR; // Something fishy found
|
2000-07-31 21:29:14 +02:00
|
|
|
break;
|
|
|
|
|
2003-03-14 15:08:12 +01:00
|
|
|
case MY_LEX_LONG_CMP_OP: // Incomplete comparison operator
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
if (state_map[lip->yyPeek()] == MY_LEX_CMP_OP ||
|
|
|
|
state_map[lip->yyPeek()] == MY_LEX_LONG_CMP_OP)
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
lip->yySkip();
|
|
|
|
if (state_map[lip->yyPeek()] == MY_LEX_CMP_OP)
|
|
|
|
lip->yySkip();
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
if ((tokval = find_keyword(lip, lip->yyLength() + 1, 0)))
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2007-04-26 05:38:12 +02:00
|
|
|
lip->next_state= MY_LEX_START; // Found long op
|
2000-07-31 21:29:14 +02:00
|
|
|
return(tokval);
|
|
|
|
}
|
2003-03-14 15:08:12 +01:00
|
|
|
state = MY_LEX_CHAR; // Something fishy found
|
2000-07-31 21:29:14 +02:00
|
|
|
break;
|
|
|
|
|
2003-03-14 15:08:12 +01:00
|
|
|
case MY_LEX_BOOL:
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
if (c != lip->yyPeek())
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2003-03-14 15:08:12 +01:00
|
|
|
state=MY_LEX_CHAR;
|
2000-07-31 21:29:14 +02:00
|
|
|
break;
|
|
|
|
}
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
lip->yySkip();
|
2007-04-26 05:38:12 +02:00
|
|
|
tokval = find_keyword(lip,2,0); // Is a bool operator
|
|
|
|
lip->next_state= MY_LEX_START; // Allow signed numbers
|
2000-07-31 21:29:14 +02:00
|
|
|
return(tokval);
|
|
|
|
|
2003-03-14 15:08:12 +01:00
|
|
|
case MY_LEX_STRING_OR_DELIMITER:
|
2007-04-26 05:38:12 +02:00
|
|
|
if (thd->variables.sql_mode & MODE_ANSI_QUOTES)
|
2003-01-17 15:33:54 +01:00
|
|
|
{
|
2003-03-14 15:08:12 +01:00
|
|
|
state= MY_LEX_USER_VARIABLE_DELIMITER;
|
2003-01-17 15:33:54 +01:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
/* " used for strings */
|
2003-03-14 15:08:12 +01:00
|
|
|
case MY_LEX_STRING: // Incomplete text string
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
if (!(yylval->lex_str.str = get_text(lip, 1, 1)))
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2003-03-14 15:08:12 +01:00
|
|
|
state= MY_LEX_CHAR; // Read char by char
|
2000-07-31 21:29:14 +02:00
|
|
|
break;
|
|
|
|
}
|
2007-04-26 05:38:12 +02:00
|
|
|
yylval->lex_str.length=lip->yytoklen;
|
Patch for the following bugs:
- BUG#11986: Stored routines and triggers can fail if the code
has a non-ascii symbol
- BUG#16291: mysqldump corrupts string-constants with non-ascii-chars
- BUG#19443: INFORMATION_SCHEMA does not support charsets properly
- BUG#21249: Character set of SP-var can be ignored
- BUG#25212: Character set of string constant is ignored (stored routines)
- BUG#25221: Character set of string constant is ignored (triggers)
There were a few general problems that caused these bugs:
1. Character set information of the original (definition) query for views,
triggers, stored routines and events was lost.
2. mysqldump output query in client character set, which can be
inappropriate to encode definition-query.
3. INFORMATION_SCHEMA used strings with mixed encodings to display object
definition;
1. No query-definition-character set.
In order to compile query into execution code, some extra data (such as
environment variables or the database character set) is used. The problem
here was that this context was not preserved. So, on the next load it can
differ from the original one, thus the result will be different.
The context contains the following data:
- client character set;
- connection collation (character set and collation);
- collation of the owner database;
The fix is to store this context and use it each time we parse (compile)
and execute the object (stored routine, trigger, ...).
2. Wrong mysqldump-output.
The original query can contain several encodings (by means of character set
introducers). The problem here was that we tried to convert original query
to the mysqldump-client character set.
Moreover, we stored queries in different character sets for different
objects (views, for one, used UTF8, triggers used original character set).
The solution is
- to store definition queries in the original character set;
- to change SHOW CREATE statement to output definition query in the
binary character set (i.e. without any conversion);
- introduce SHOW CREATE TRIGGER statement;
- to dump special statements to switch the context to the original one
before dumping and restore it afterwards.
Note, in order to preserve the database collation at the creation time,
additional ALTER DATABASE might be used (to temporary switch the database
collation back to the original value). In this case, ALTER DATABASE
privilege will be required. This is a backward-incompatible change.
3. INFORMATION_SCHEMA showed non-UTF8 strings
The fix is to generate UTF8-query during the parsing, store it in the object
and show it in the INFORMATION_SCHEMA.
Basically, the idea is to create a copy of the original query convert it to
UTF8. Character set introducers are removed and all text literals are
converted to UTF8.
This UTF8 query is intended to provide user-readable output. It must not be
used to recreate the object. Specialized SHOW CREATE statements should be
used for this.
The reason for this limitation is the following: the original query can
contain symbols from several character sets (by means of character set
introducers).
Example:
- original query:
CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1;
- UTF8 query (for INFORMATION_SCHEMA):
CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 19:34:54 +02:00
|
|
|
|
|
|
|
lip->body_utf8_append(lip->m_cpp_text_start);
|
|
|
|
|
|
|
|
lip->body_utf8_append_literal(thd, &yylval->lex_str,
|
|
|
|
lip->m_underscore_cs ? lip->m_underscore_cs : cs,
|
|
|
|
lip->m_cpp_text_end);
|
|
|
|
|
|
|
|
lip->m_underscore_cs= NULL;
|
|
|
|
|
2007-08-03 12:25:23 +02:00
|
|
|
lex->text_string_is_7bit= (lip->tok_bitmap & 0x80) ? 0 : 1;
|
2000-07-31 21:29:14 +02:00
|
|
|
return(TEXT_STRING);
|
|
|
|
|
2003-03-14 15:08:12 +01:00
|
|
|
case MY_LEX_COMMENT: // Comment
|
2002-02-15 01:49:02 +01:00
|
|
|
lex->select_lex.options|= OPTION_FOUND_COMMENT;
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
while ((c = lip->yyGet()) != '\n' && c) ;
|
|
|
|
lip->yyUnget(); // Safety against eof
|
2003-03-14 15:08:12 +01:00
|
|
|
state = MY_LEX_START; // Try again
|
2000-07-31 21:29:14 +02:00
|
|
|
break;
|
2003-03-14 15:08:12 +01:00
|
|
|
case MY_LEX_LONG_COMMENT: /* Long C comment? */
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
if (lip->yyPeek() != '*')
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2003-03-14 15:08:12 +01:00
|
|
|
state=MY_LEX_CHAR; // Probable division
|
2000-07-31 21:29:14 +02:00
|
|
|
break;
|
|
|
|
}
|
2002-02-15 01:49:02 +01:00
|
|
|
lex->select_lex.options|= OPTION_FOUND_COMMENT;
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
/* Reject '/' '*', since we might need to turn off the echo */
|
|
|
|
lip->yyUnget();
|
|
|
|
|
2009-04-10 04:18:18 +02:00
|
|
|
lip->save_in_comment_state();
|
|
|
|
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
if (lip->yyPeekn(2) == '!')
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
lip->in_comment= DISCARD_COMMENT;
|
|
|
|
/* Accept '/' '*' '!', but do not keep this marker. */
|
2007-07-20 17:52:25 +02:00
|
|
|
lip->set_echo(FALSE);
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
lip->yySkip();
|
|
|
|
lip->yySkip();
|
|
|
|
lip->yySkip();
|
|
|
|
|
|
|
|
/*
|
|
|
|
The special comment format is very strict:
|
|
|
|
'/' '*' '!', followed by exactly
|
2007-08-30 20:57:05 +02:00
|
|
|
1 digit (major), 2 digits (minor), then 2 digits (dot).
|
|
|
|
32302 -> 3.23.02
|
|
|
|
50032 -> 5.0.32
|
|
|
|
50114 -> 5.1.14
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
*/
|
|
|
|
char version_str[6];
|
|
|
|
version_str[0]= lip->yyPeekn(0);
|
|
|
|
version_str[1]= lip->yyPeekn(1);
|
|
|
|
version_str[2]= lip->yyPeekn(2);
|
|
|
|
version_str[3]= lip->yyPeekn(3);
|
|
|
|
version_str[4]= lip->yyPeekn(4);
|
|
|
|
version_str[5]= 0;
|
|
|
|
if ( my_isdigit(cs, version_str[0])
|
|
|
|
&& my_isdigit(cs, version_str[1])
|
|
|
|
&& my_isdigit(cs, version_str[2])
|
|
|
|
&& my_isdigit(cs, version_str[3])
|
|
|
|
&& my_isdigit(cs, version_str[4])
|
|
|
|
)
|
|
|
|
{
|
|
|
|
ulong version;
|
|
|
|
version=strtol(version_str, NULL, 10);
|
|
|
|
|
2007-08-30 20:57:05 +02:00
|
|
|
/* Accept 'M' 'm' 'm' 'd' 'd' */
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
lip->yySkipn(5);
|
|
|
|
|
|
|
|
if (version <= MYSQL_VERSION_ID)
|
|
|
|
{
|
|
|
|
/* Expand the content of the special comment as real code */
|
2007-07-20 17:52:25 +02:00
|
|
|
lip->set_echo(TRUE);
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
state=MY_LEX_START;
|
2009-04-10 04:18:18 +02:00
|
|
|
break; /* Do not treat contents as a comment. */
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
comment_closed= ! consume_comment(lip, 1);
|
|
|
|
/* version allowed to have one level of comment inside. */
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2009-04-10 04:18:18 +02:00
|
|
|
/* Not a version comment. */
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
state=MY_LEX_START;
|
2007-07-20 17:52:25 +02:00
|
|
|
lip->set_echo(TRUE);
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
break;
|
|
|
|
}
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
else
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
lip->in_comment= PRESERVE_COMMENT;
|
|
|
|
lip->yySkip(); // Accept /
|
|
|
|
lip->yySkip(); // Accept *
|
2009-04-10 04:18:18 +02:00
|
|
|
comment_closed= ! consume_comment(lip, 0);
|
|
|
|
/* regular comments can have zero comments inside. */
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
2007-08-30 20:57:05 +02:00
|
|
|
/*
|
|
|
|
Discard:
|
|
|
|
- regular '/' '*' comments,
|
|
|
|
- special comments '/' '*' '!' for a future version,
|
|
|
|
by scanning until we find a closing '*' '/' marker.
|
2009-04-10 04:18:18 +02:00
|
|
|
|
|
|
|
Nesting regular comments isn't allowed. The first
|
|
|
|
'*' '/' returns the parser to the previous state.
|
|
|
|
|
|
|
|
/#!VERSI oned containing /# regular #/ is allowed #/
|
|
|
|
|
|
|
|
Inside one versioned comment, another versioned comment
|
|
|
|
is treated as a regular discardable comment. It gets
|
|
|
|
no special parsing.
|
2007-08-30 20:57:05 +02:00
|
|
|
*/
|
2009-04-10 04:18:18 +02:00
|
|
|
|
2007-08-30 20:57:05 +02:00
|
|
|
/* Unbalanced comments with a missing '*' '/' are a syntax error */
|
|
|
|
if (! comment_closed)
|
|
|
|
return (ABORT_SYM);
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
state = MY_LEX_START; // Try again
|
2009-04-10 04:18:18 +02:00
|
|
|
lip->restore_in_comment_state();
|
2000-07-31 21:29:14 +02:00
|
|
|
break;
|
2003-03-14 15:08:12 +01:00
|
|
|
case MY_LEX_END_LONG_COMMENT:
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
if ((lip->in_comment != NO_COMMENT) && lip->yyPeek() == '/')
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
/* Reject '*' '/' */
|
|
|
|
lip->yyUnget();
|
|
|
|
/* Accept '*' '/', with the proper echo */
|
|
|
|
lip->set_echo(lip->in_comment == PRESERVE_COMMENT);
|
|
|
|
lip->yySkipn(2);
|
|
|
|
/* And start recording the tokens again */
|
2007-07-20 17:52:25 +02:00
|
|
|
lip->set_echo(TRUE);
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
lip->in_comment=NO_COMMENT;
|
|
|
|
state=MY_LEX_START;
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
|
|
|
else
|
2003-03-14 15:08:12 +01:00
|
|
|
state=MY_LEX_CHAR; // Return '*'
|
2000-07-31 21:29:14 +02:00
|
|
|
break;
|
2003-07-06 18:09:57 +02:00
|
|
|
case MY_LEX_SET_VAR: // Check if ':='
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
if (lip->yyPeek() != '=')
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2003-03-14 15:08:12 +01:00
|
|
|
state=MY_LEX_CHAR; // Return ':'
|
2000-07-31 21:29:14 +02:00
|
|
|
break;
|
|
|
|
}
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
lip->yySkip();
|
2000-07-31 21:29:14 +02:00
|
|
|
return (SET_VAR);
|
2004-04-27 23:49:05 +02:00
|
|
|
case MY_LEX_SEMICOLON: // optional line terminator
|
2008-07-07 18:00:08 +02:00
|
|
|
state= MY_LEX_CHAR; // Return ';'
|
|
|
|
break;
|
2003-03-14 15:08:12 +01:00
|
|
|
case MY_LEX_EOL:
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
if (lip->eof())
|
2004-02-12 13:01:27 +01:00
|
|
|
{
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
lip->yyUnget(); // Reject the last '\0'
|
2007-07-20 17:52:25 +02:00
|
|
|
lip->set_echo(FALSE);
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
lip->yySkip();
|
2007-07-20 17:52:25 +02:00
|
|
|
lip->set_echo(TRUE);
|
2007-08-30 20:57:05 +02:00
|
|
|
/* Unbalanced comments with a missing '*' '/' are a syntax error */
|
|
|
|
if (lip->in_comment != NO_COMMENT)
|
|
|
|
return (ABORT_SYM);
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
lip->next_state=MY_LEX_END; // Mark for next loop
|
|
|
|
return(END_OF_INPUT);
|
2004-02-12 13:01:27 +01:00
|
|
|
}
|
|
|
|
state=MY_LEX_CHAR;
|
|
|
|
break;
|
2003-03-14 15:08:12 +01:00
|
|
|
case MY_LEX_END:
|
2007-04-26 05:38:12 +02:00
|
|
|
lip->next_state=MY_LEX_END;
|
2000-07-31 21:29:14 +02:00
|
|
|
return(0); // We found end of input last time
|
2008-07-07 18:00:08 +02:00
|
|
|
|
2002-11-21 01:07:14 +01:00
|
|
|
/* Actually real shouldn't start with . but allow them anyhow */
|
2003-03-14 15:08:12 +01:00
|
|
|
case MY_LEX_REAL_OR_POINT:
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
if (my_isdigit(cs,lip->yyPeek()))
|
2003-03-14 15:08:12 +01:00
|
|
|
state = MY_LEX_REAL; // Real
|
2000-07-31 21:29:14 +02:00
|
|
|
else
|
|
|
|
{
|
2003-07-06 18:09:57 +02:00
|
|
|
state= MY_LEX_IDENT_SEP; // return '.'
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
lip->yyUnget(); // Put back '.'
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
|
|
|
break;
|
2003-03-14 15:08:12 +01:00
|
|
|
case MY_LEX_USER_END: // end '@' of user@hostname
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
switch (state_map[lip->yyPeek()]) {
|
2003-03-14 15:08:12 +01:00
|
|
|
case MY_LEX_STRING:
|
|
|
|
case MY_LEX_USER_VARIABLE_DELIMITER:
|
|
|
|
case MY_LEX_STRING_OR_DELIMITER:
|
2001-09-11 01:30:29 +02:00
|
|
|
break;
|
2003-03-14 15:08:12 +01:00
|
|
|
case MY_LEX_USER_END:
|
2007-04-26 05:38:12 +02:00
|
|
|
lip->next_state=MY_LEX_SYSTEM_VAR;
|
2001-09-11 01:30:29 +02:00
|
|
|
break;
|
|
|
|
default:
|
2007-04-26 05:38:12 +02:00
|
|
|
lip->next_state=MY_LEX_HOSTNAME;
|
2001-09-11 01:30:29 +02:00
|
|
|
break;
|
|
|
|
}
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
yylval->lex_str.str=(char*) lip->get_ptr();
|
2000-07-31 21:29:14 +02:00
|
|
|
yylval->lex_str.length=1;
|
|
|
|
return((int) '@');
|
2003-03-14 15:08:12 +01:00
|
|
|
case MY_LEX_HOSTNAME: // end '@' of user@hostname
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
for (c=lip->yyGet() ;
|
2003-03-14 15:08:12 +01:00
|
|
|
my_isalnum(cs,c) || c == '.' || c == '_' || c == '$';
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
c= lip->yyGet()) ;
|
|
|
|
yylval->lex_str=get_token(lip, 0, lip->yyLength());
|
2000-07-31 21:29:14 +02:00
|
|
|
return(LEX_HOSTNAME);
|
2003-03-14 15:08:12 +01:00
|
|
|
case MY_LEX_SYSTEM_VAR:
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
yylval->lex_str.str=(char*) lip->get_ptr();
|
2002-07-23 17:31:22 +02:00
|
|
|
yylval->lex_str.length=1;
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
lip->yySkip(); // Skip '@'
|
|
|
|
lip->next_state= (state_map[lip->yyPeek()] ==
|
2003-07-06 18:09:57 +02:00
|
|
|
MY_LEX_USER_VARIABLE_DELIMITER ?
|
|
|
|
MY_LEX_OPERATOR_OR_IDENT :
|
|
|
|
MY_LEX_IDENT_OR_KEYWORD);
|
2002-07-23 17:31:22 +02:00
|
|
|
return((int) '@');
|
2003-03-14 15:08:12 +01:00
|
|
|
case MY_LEX_IDENT_OR_KEYWORD:
|
2002-07-23 17:31:22 +02:00
|
|
|
/*
|
|
|
|
We come here when we have found two '@' in a row.
|
|
|
|
We should now be able to handle:
|
|
|
|
[(global | local | session) .]variable_name
|
|
|
|
*/
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
|
2009-06-17 16:56:44 +02:00
|
|
|
for (result_state= 0; ident_map[c= lip->yyGet()]; result_state|= c) ;
|
2004-06-10 16:10:21 +02:00
|
|
|
/* If there were non-ASCII characters, mark that we must convert */
|
|
|
|
result_state= result_state & 0x80 ? IDENT_QUOTED : IDENT;
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
|
2002-07-23 17:31:22 +02:00
|
|
|
if (c == '.')
|
2007-04-26 05:38:12 +02:00
|
|
|
lip->next_state=MY_LEX_IDENT_SEP;
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
length= lip->yyLength();
|
|
|
|
if (length == 0)
|
2006-08-15 18:41:21 +02:00
|
|
|
return(ABORT_SYM); // Names must be nonempty.
|
2007-04-26 05:38:12 +02:00
|
|
|
if ((tokval= find_keyword(lip, length,0)))
|
2002-07-23 17:31:22 +02:00
|
|
|
{
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
lip->yyUnget(); // Put back 'c'
|
2002-07-23 17:31:22 +02:00
|
|
|
return(tokval); // Was keyword
|
|
|
|
}
|
Bug#21513 (SP having body starting with quoted label rendered unusable)
Before this fix, the parser would sometime change where a token starts by
altering Lex_input_string::tok_start, which later confused the code in
sql_yacc.yy that needs to capture the source code of a SQL statement,
like to represent the body of a stored procedure.
This line of code in sql_lex.cc :
case MY_LEX_USER_VARIABLE_DELIMITER:
lip->tok_start= lip->ptr; // Skip first `
would <skip the first back quote> ... and cause the bug reported.
In general, the responsibility of sql_lex.cc is to *find* where token are
in the SQL text, but is *not* to make up fake or incomplete tokens.
With a quoted label like `my_label`, the token starts on the first quote.
Extracting the token value should not change that (it did).
With this fix, the lexical analysis has been cleaned up to not change
lip->tok_start (in the case found for this bug).
The functions get_token() and get_quoted_token() now have an extra
parameters, used when some characters from the beginning of the token need
to be skipped when extracting a token value, like when extracting 'AB' from
'0xAB', for example, for a HEX_NUM token.
This exposed a bad assumption in Item_hex_string and Item_bin_string,
which has been fixed:
The assumption was that the string given, 'AB', was in fact preceded in
memory by '0x', which might be false (it can be preceded by "x'" and
followed by "'" -- or not be preceded by valid memory at all)
If a name is needed for Item_hex_string or Item_bin_string, the name is
taken from the original and true source code ('0xAB'), and assigned in
the select_item rule, instead of relying on assumptions related to how
memory is used.
2007-04-28 01:14:25 +02:00
|
|
|
yylval->lex_str=get_token(lip, 0, length);
|
Patch for the following bugs:
- BUG#11986: Stored routines and triggers can fail if the code
has a non-ascii symbol
- BUG#16291: mysqldump corrupts string-constants with non-ascii-chars
- BUG#19443: INFORMATION_SCHEMA does not support charsets properly
- BUG#21249: Character set of SP-var can be ignored
- BUG#25212: Character set of string constant is ignored (stored routines)
- BUG#25221: Character set of string constant is ignored (triggers)
There were a few general problems that caused these bugs:
1. Character set information of the original (definition) query for views,
triggers, stored routines and events was lost.
2. mysqldump output query in client character set, which can be
inappropriate to encode definition-query.
3. INFORMATION_SCHEMA used strings with mixed encodings to display object
definition;
1. No query-definition-character set.
In order to compile query into execution code, some extra data (such as
environment variables or the database character set) is used. The problem
here was that this context was not preserved. So, on the next load it can
differ from the original one, thus the result will be different.
The context contains the following data:
- client character set;
- connection collation (character set and collation);
- collation of the owner database;
The fix is to store this context and use it each time we parse (compile)
and execute the object (stored routine, trigger, ...).
2. Wrong mysqldump-output.
The original query can contain several encodings (by means of character set
introducers). The problem here was that we tried to convert original query
to the mysqldump-client character set.
Moreover, we stored queries in different character sets for different
objects (views, for one, used UTF8, triggers used original character set).
The solution is
- to store definition queries in the original character set;
- to change SHOW CREATE statement to output definition query in the
binary character set (i.e. without any conversion);
- introduce SHOW CREATE TRIGGER statement;
- to dump special statements to switch the context to the original one
before dumping and restore it afterwards.
Note, in order to preserve the database collation at the creation time,
additional ALTER DATABASE might be used (to temporary switch the database
collation back to the original value). In this case, ALTER DATABASE
privilege will be required. This is a backward-incompatible change.
3. INFORMATION_SCHEMA showed non-UTF8 strings
The fix is to generate UTF8-query during the parsing, store it in the object
and show it in the INFORMATION_SCHEMA.
Basically, the idea is to create a copy of the original query convert it to
UTF8. Character set introducers are removed and all text literals are
converted to UTF8.
This UTF8 query is intended to provide user-readable output. It must not be
used to recreate the object. Specialized SHOW CREATE statements should be
used for this.
The reason for this limitation is the following: the original query can
contain symbols from several character sets (by means of character set
introducers).
Example:
- original query:
CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1;
- UTF8 query (for INFORMATION_SCHEMA):
CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 19:34:54 +02:00
|
|
|
|
|
|
|
lip->body_utf8_append(lip->m_cpp_text_start);
|
|
|
|
|
|
|
|
lip->body_utf8_append_literal(thd, &yylval->lex_str, cs,
|
|
|
|
lip->m_cpp_text_end);
|
|
|
|
|
2003-11-03 13:01:59 +01:00
|
|
|
return(result_state);
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2002-05-06 23:04:16 +02:00
|
|
|
|
2006-07-28 00:49:18 +02:00
|
|
|
|
2007-08-15 15:43:08 +02:00
|
|
|
/**
|
|
|
|
Construct a copy of this object to be used for mysql_alter_table
|
|
|
|
and mysql_create_table.
|
2006-07-28 00:49:18 +02:00
|
|
|
|
2007-08-15 15:43:08 +02:00
|
|
|
Historically, these two functions modify their Alter_info
|
|
|
|
arguments. This behaviour breaks re-execution of prepared
|
|
|
|
statements and stored procedures and is compensated by always
|
|
|
|
supplying a copy of Alter_info to these functions.
|
2006-07-28 00:49:18 +02:00
|
|
|
|
2007-08-15 15:43:08 +02:00
|
|
|
@return You need to use check the error in THD for out
|
|
|
|
of memory condition after calling this function.
|
2006-07-28 00:49:18 +02:00
|
|
|
*/
|
|
|
|
|
5.1 version of a fix and test cases for bugs:
Bug#4968 ""Stored procedure crash if cursor opened on altered table"
Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing"
Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from
stored procedure."
Bug#19733 "Repeated alter, or repeated create/drop, fails"
Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server"
Bug#24879 "Prepared Statements: CREATE TABLE (UTF8 KEY) produces a
growing key length" (this bug is not fixed in 5.0)
Re-execution of CREATE DATABASE, CREATE TABLE and ALTER TABLE
statements in stored routines or as prepared statements caused
incorrect results (and crashes in versions prior to 5.0.25).
In 5.1 the problem occured only for CREATE DATABASE, CREATE TABLE
SELECT and CREATE TABLE with INDEX/DATA DIRECTOY options).
The problem of bugs 4968, 19733, 19282 and 6895 was that functions
mysql_prepare_table, mysql_create_table and mysql_alter_table are not
re-execution friendly: during their operation they modify contents
of LEX (members create_info, alter_info, key_list, create_list),
thus making the LEX unusable for the next execution.
In particular, these functions removed processed columns and keys from
create_list, key_list and drop_list. Search the code in sql_table.cc
for drop_it.remove() and similar patterns to find evidence.
The fix is to supply to these functions a usable copy of each of the
above structures at every re-execution of an SQL statement.
To simplify memory management, LEX::key_list and LEX::create_list
were added to LEX::alter_info, a fresh copy of which is created for
every execution.
The problem of crashing bug 22060 stemmed from the fact that the above
metnioned functions were not only modifying HA_CREATE_INFO structure
in LEX, but also were changing it to point to areas in volatile memory
of the execution memory root.
The patch solves this problem by creating and using an on-stack
copy of HA_CREATE_INFO in mysql_execute_command.
Additionally, this patch splits the part of mysql_alter_table
that analizes and rewrites information from the parser into
a separate function - mysql_prepare_alter_table, in analogy with
mysql_prepare_table, which is renamed to mysql_prepare_create_table.
2007-05-28 13:30:01 +02:00
|
|
|
Alter_info::Alter_info(const Alter_info &rhs, MEM_ROOT *mem_root)
|
|
|
|
:drop_list(rhs.drop_list, mem_root),
|
|
|
|
alter_list(rhs.alter_list, mem_root),
|
|
|
|
key_list(rhs.key_list, mem_root),
|
|
|
|
create_list(rhs.create_list, mem_root),
|
|
|
|
flags(rhs.flags),
|
|
|
|
keys_onoff(rhs.keys_onoff),
|
|
|
|
tablespace_op(rhs.tablespace_op),
|
|
|
|
partition_names(rhs.partition_names, mem_root),
|
2009-10-01 15:04:42 +02:00
|
|
|
num_parts(rhs.num_parts),
|
2007-06-04 12:03:15 +02:00
|
|
|
change_level(rhs.change_level),
|
|
|
|
datetime_field(rhs.datetime_field),
|
|
|
|
error_if_not_empty(rhs.error_if_not_empty)
|
2006-07-28 00:49:18 +02:00
|
|
|
{
|
5.1 version of a fix and test cases for bugs:
Bug#4968 ""Stored procedure crash if cursor opened on altered table"
Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing"
Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from
stored procedure."
Bug#19733 "Repeated alter, or repeated create/drop, fails"
Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server"
Bug#24879 "Prepared Statements: CREATE TABLE (UTF8 KEY) produces a
growing key length" (this bug is not fixed in 5.0)
Re-execution of CREATE DATABASE, CREATE TABLE and ALTER TABLE
statements in stored routines or as prepared statements caused
incorrect results (and crashes in versions prior to 5.0.25).
In 5.1 the problem occured only for CREATE DATABASE, CREATE TABLE
SELECT and CREATE TABLE with INDEX/DATA DIRECTOY options).
The problem of bugs 4968, 19733, 19282 and 6895 was that functions
mysql_prepare_table, mysql_create_table and mysql_alter_table are not
re-execution friendly: during their operation they modify contents
of LEX (members create_info, alter_info, key_list, create_list),
thus making the LEX unusable for the next execution.
In particular, these functions removed processed columns and keys from
create_list, key_list and drop_list. Search the code in sql_table.cc
for drop_it.remove() and similar patterns to find evidence.
The fix is to supply to these functions a usable copy of each of the
above structures at every re-execution of an SQL statement.
To simplify memory management, LEX::key_list and LEX::create_list
were added to LEX::alter_info, a fresh copy of which is created for
every execution.
The problem of crashing bug 22060 stemmed from the fact that the above
metnioned functions were not only modifying HA_CREATE_INFO structure
in LEX, but also were changing it to point to areas in volatile memory
of the execution memory root.
The patch solves this problem by creating and using an on-stack
copy of HA_CREATE_INFO in mysql_execute_command.
Additionally, this patch splits the part of mysql_alter_table
that analizes and rewrites information from the parser into
a separate function - mysql_prepare_alter_table, in analogy with
mysql_prepare_table, which is renamed to mysql_prepare_create_table.
2007-05-28 13:30:01 +02:00
|
|
|
/*
|
|
|
|
Make deep copies of used objects.
|
|
|
|
This is not a fully deep copy - clone() implementations
|
2007-06-10 12:43:57 +02:00
|
|
|
of Alter_drop, Alter_column, Key, foreign_key, Key_part_spec
|
5.1 version of a fix and test cases for bugs:
Bug#4968 ""Stored procedure crash if cursor opened on altered table"
Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing"
Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from
stored procedure."
Bug#19733 "Repeated alter, or repeated create/drop, fails"
Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server"
Bug#24879 "Prepared Statements: CREATE TABLE (UTF8 KEY) produces a
growing key length" (this bug is not fixed in 5.0)
Re-execution of CREATE DATABASE, CREATE TABLE and ALTER TABLE
statements in stored routines or as prepared statements caused
incorrect results (and crashes in versions prior to 5.0.25).
In 5.1 the problem occured only for CREATE DATABASE, CREATE TABLE
SELECT and CREATE TABLE with INDEX/DATA DIRECTOY options).
The problem of bugs 4968, 19733, 19282 and 6895 was that functions
mysql_prepare_table, mysql_create_table and mysql_alter_table are not
re-execution friendly: during their operation they modify contents
of LEX (members create_info, alter_info, key_list, create_list),
thus making the LEX unusable for the next execution.
In particular, these functions removed processed columns and keys from
create_list, key_list and drop_list. Search the code in sql_table.cc
for drop_it.remove() and similar patterns to find evidence.
The fix is to supply to these functions a usable copy of each of the
above structures at every re-execution of an SQL statement.
To simplify memory management, LEX::key_list and LEX::create_list
were added to LEX::alter_info, a fresh copy of which is created for
every execution.
The problem of crashing bug 22060 stemmed from the fact that the above
metnioned functions were not only modifying HA_CREATE_INFO structure
in LEX, but also were changing it to point to areas in volatile memory
of the execution memory root.
The patch solves this problem by creating and using an on-stack
copy of HA_CREATE_INFO in mysql_execute_command.
Additionally, this patch splits the part of mysql_alter_table
that analizes and rewrites information from the parser into
a separate function - mysql_prepare_alter_table, in analogy with
mysql_prepare_table, which is renamed to mysql_prepare_create_table.
2007-05-28 13:30:01 +02:00
|
|
|
do not copy string constants. At the same length the only
|
|
|
|
reason we make a copy currently is that ALTER/CREATE TABLE
|
|
|
|
code changes input Alter_info definitions, but string
|
|
|
|
constants never change.
|
|
|
|
*/
|
|
|
|
list_copy_and_replace_each_value(drop_list, mem_root);
|
|
|
|
list_copy_and_replace_each_value(alter_list, mem_root);
|
|
|
|
list_copy_and_replace_each_value(key_list, mem_root);
|
|
|
|
list_copy_and_replace_each_value(create_list, mem_root);
|
|
|
|
/* partition_names are not deeply copied currently */
|
|
|
|
}
|
|
|
|
|
|
|
|
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
void trim_whitespace(CHARSET_INFO *cs, LEX_STRING *str)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
TODO:
|
|
|
|
This code assumes that there are no multi-bytes characters
|
|
|
|
that can be considered white-space.
|
|
|
|
*/
|
2006-07-28 00:49:18 +02:00
|
|
|
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
while ((str->length > 0) && (my_isspace(cs, str->str[0])))
|
|
|
|
{
|
|
|
|
str->length --;
|
|
|
|
str->str ++;
|
|
|
|
}
|
2006-07-28 00:49:18 +02:00
|
|
|
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
/*
|
|
|
|
FIXME:
|
|
|
|
Also, parsing backward is not safe with multi bytes characters
|
|
|
|
*/
|
|
|
|
while ((str->length > 0) && (my_isspace(cs, str->str[str->length-1])))
|
|
|
|
{
|
|
|
|
str->length --;
|
|
|
|
}
|
2006-07-28 00:49:18 +02:00
|
|
|
}
|
|
|
|
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
2007-06-12 23:23:58 +02:00
|
|
|
|
2002-05-06 23:04:16 +02:00
|
|
|
/*
|
|
|
|
st_select_lex structures initialisations
|
|
|
|
*/
|
|
|
|
|
|
|
|
void st_select_lex_node::init_query()
|
|
|
|
{
|
2003-03-05 22:32:59 +01:00
|
|
|
options= 0;
|
2006-06-27 19:28:32 +02:00
|
|
|
sql_cache= SQL_CACHE_UNSPECIFIED;
|
2003-03-05 22:32:59 +01:00
|
|
|
linkage= UNSPECIFIED_TYPE;
|
2003-11-17 19:53:40 +01:00
|
|
|
no_error= no_table_names_allowed= 0;
|
|
|
|
uncacheable= 0;
|
2002-05-06 23:04:16 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
void st_select_lex_node::init_select()
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
void st_select_lex_unit::init_query()
|
|
|
|
{
|
|
|
|
st_select_lex_node::init_query();
|
2003-03-05 22:32:59 +01:00
|
|
|
linkage= GLOBAL_OPTIONS_TYPE;
|
2003-07-03 01:30:52 +02:00
|
|
|
global_parameters= first_select();
|
2002-05-08 22:14:40 +02:00
|
|
|
select_limit_cnt= HA_POS_ERROR;
|
|
|
|
offset_limit_cnt= 0;
|
2004-03-23 14:43:24 +01:00
|
|
|
union_distinct= 0;
|
2002-10-27 20:29:40 +01:00
|
|
|
prepared= optimized= executed= 0;
|
2002-09-03 08:50:36 +02:00
|
|
|
item= 0;
|
2003-01-25 01:25:52 +01:00
|
|
|
union_result= 0;
|
|
|
|
table= 0;
|
2003-07-03 01:30:52 +02:00
|
|
|
fake_select_lex= 0;
|
2004-02-10 01:18:22 +01:00
|
|
|
cleaned= 0;
|
2004-03-23 13:26:54 +01:00
|
|
|
item_list.empty();
|
2004-05-06 19:40:21 +02:00
|
|
|
describe= 0;
|
2003-11-21 20:19:56 +01:00
|
|
|
found_rows_for_union= 0;
|
2002-05-06 23:04:16 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
void st_select_lex::init_query()
|
|
|
|
{
|
|
|
|
st_select_lex_node::init_query();
|
2003-03-05 22:32:59 +01:00
|
|
|
table_list.empty();
|
2004-06-11 07:27:21 +02:00
|
|
|
top_join_list.empty();
|
|
|
|
join_list= &top_join_list;
|
2004-09-14 18:28:29 +02:00
|
|
|
embedding= leaf_tables= 0;
|
2002-05-06 23:04:16 +02:00
|
|
|
item_list.empty();
|
2002-10-15 23:42:59 +02:00
|
|
|
join= 0;
|
2006-02-03 06:23:36 +01:00
|
|
|
having= prep_having= where= prep_where= 0;
|
2002-11-09 14:40:46 +01:00
|
|
|
olap= UNSPECIFIED_OLAP_TYPE;
|
2003-07-29 15:59:46 +02:00
|
|
|
having_fix_field= 0;
|
2010-02-06 20:54:30 +01:00
|
|
|
group_fix_field= 0;
|
2005-07-01 06:05:42 +02:00
|
|
|
context.select_lex= this;
|
|
|
|
context.init();
|
2005-08-12 16:57:19 +02:00
|
|
|
/*
|
|
|
|
Add the name resolution context of the current (sub)query to the
|
|
|
|
stack of contexts for the whole query.
|
2005-11-28 20:57:50 +01:00
|
|
|
TODO:
|
|
|
|
push_context may return an error if there is no memory for a new
|
|
|
|
element in the stack, however this method has no return value,
|
|
|
|
thus push_context should be moved to a place where query
|
|
|
|
initialization is checked for failure.
|
2005-08-12 16:57:19 +02:00
|
|
|
*/
|
|
|
|
parent_lex->push_context(&context);
|
2006-10-16 23:25:28 +02:00
|
|
|
cond_count= between_count= with_wild= 0;
|
2007-08-15 19:24:18 +02:00
|
|
|
max_equal_elems= 0;
|
2003-07-03 01:30:52 +02:00
|
|
|
ref_pointer_array= 0;
|
2007-02-24 21:04:15 +01:00
|
|
|
select_n_where_fields= 0;
|
2003-08-16 12:26:48 +02:00
|
|
|
select_n_having_items= 0;
|
2004-06-09 22:32:20 +02:00
|
|
|
subquery_in_having= explicit_limit= 0;
|
2005-10-12 22:58:59 +02:00
|
|
|
is_item_list_lookup= 0;
|
2004-05-20 01:02:49 +02:00
|
|
|
first_execution= 1;
|
2008-10-07 23:34:00 +02:00
|
|
|
first_natural_join_processing= 1;
|
2004-06-30 14:54:32 +02:00
|
|
|
first_cond_optimization= 1;
|
2004-09-09 05:59:26 +02:00
|
|
|
parsing_place= NO_MATTER;
|
2005-03-28 14:13:31 +02:00
|
|
|
exclude_from_table_unique_test= no_wrap_view_item= FALSE;
|
2005-10-15 23:32:37 +02:00
|
|
|
nest_level= 0;
|
2004-11-13 11:56:39 +01:00
|
|
|
link_next= 0;
|
2002-05-06 23:04:16 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
void st_select_lex::init_select()
|
|
|
|
{
|
|
|
|
st_select_lex_node::init_select();
|
2003-03-05 22:32:59 +01:00
|
|
|
group_list.empty();
|
2005-08-12 16:57:19 +02:00
|
|
|
type= db= 0;
|
2003-03-05 22:32:59 +01:00
|
|
|
having= 0;
|
|
|
|
table_join_options= 0;
|
|
|
|
in_sum_expr= with_wild= 0;
|
2002-05-06 23:04:16 +02:00
|
|
|
options= 0;
|
2006-06-27 19:28:32 +02:00
|
|
|
sql_cache= SQL_CACHE_UNSPECIFIED;
|
2003-03-05 22:32:59 +01:00
|
|
|
braces= 0;
|
2004-07-21 21:44:12 +02:00
|
|
|
interval_list.empty();
|
2002-09-03 08:50:36 +02:00
|
|
|
ftfunc_list_alloc.empty();
|
2005-10-15 23:32:37 +02:00
|
|
|
inner_sum_func_list= 0;
|
2002-09-03 08:50:36 +02:00
|
|
|
ftfunc_list= &ftfunc_list_alloc;
|
2003-02-10 16:59:16 +01:00
|
|
|
linkage= UNSPECIFIED_TYPE;
|
2003-07-03 01:30:52 +02:00
|
|
|
order_list.elements= 0;
|
|
|
|
order_list.first= 0;
|
WL#3817: Simplify string / memory area types and make things more consistent (first part)
The following type conversions was done:
- Changed byte to uchar
- Changed gptr to uchar*
- Change my_string to char *
- Change my_size_t to size_t
- Change size_s to size_t
Removed declaration of byte, gptr, my_string, my_size_t and size_s.
Following function parameter changes was done:
- All string functions in mysys/strings was changed to use size_t
instead of uint for string lengths.
- All read()/write() functions changed to use size_t (including vio).
- All protocoll functions changed to use size_t instead of uint
- Functions that used a pointer to a string length was changed to use size_t*
- Changed malloc(), free() and related functions from using gptr to use void *
as this requires fewer casts in the code and is more in line with how the
standard functions work.
- Added extra length argument to dirname_part() to return the length of the
created string.
- Changed (at least) following functions to take uchar* as argument:
- db_dump()
- my_net_write()
- net_write_command()
- net_store_data()
- DBUG_DUMP()
- decimal2bin() & bin2decimal()
- Changed my_compress() and my_uncompress() to use size_t. Changed one
argument to my_uncompress() from a pointer to a value as we only return
one value (makes function easier to use).
- Changed type of 'pack_data' argument to packfrm() to avoid casts.
- Changed in readfrm() and writefrom(), ha_discover and handler::discover()
the type for argument 'frmdata' to uchar** to avoid casts.
- Changed most Field functions to use uchar* instead of char* (reduced a lot of
casts).
- Changed field->val_xxx(xxx, new_ptr) to take const pointers.
Other changes:
- Removed a lot of not needed casts
- Added a few new cast required by other changes
- Added some cast to my_multi_malloc() arguments for safety (as string lengths
needs to be uint, not size_t).
- Fixed all calls to hash-get-key functions to use size_t*. (Needed to be done
explicitely as this conflict was often hided by casting the function to
hash_get_key).
- Changed some buffers to memory regions to uchar* to avoid casts.
- Changed some string lengths from uint to size_t.
- Changed field->ptr to be uchar* instead of char*. This allowed us to
get rid of a lot of casts.
- Some changes from true -> TRUE, false -> FALSE, unsigned char -> uchar
- Include zlib.h in some files as we needed declaration of crc32()
- Changed MY_FILE_ERROR to be (size_t) -1.
- Changed many variables to hold the result of my_read() / my_write() to be
size_t. This was needed to properly detect errors (which are
returned as (size_t) -1).
- Removed some very old VMS code
- Changed packfrm()/unpackfrm() to not be depending on uint size
(portability fix)
- Removed windows specific code to restore cursor position as this
causes slowdown on windows and we should not mix read() and pread()
calls anyway as this is not thread safe. Updated function comment to
reflect this. Changed function that depended on original behavior of
my_pwrite() to itself restore the cursor position (one such case).
- Added some missing checking of return value of malloc().
- Changed definition of MOD_PAD_CHAR_TO_FULL_LENGTH to avoid 'long' overflow.
- Changed type of table_def::m_size from my_size_t to ulong to reflect that
m_size is the number of elements in the array, not a string/memory
length.
- Moved THD::max_row_length() to table.cc (as it's not depending on THD).
Inlined max_row_length_blob() into this function.
- More function comments
- Fixed some compiler warnings when compiled without partitions.
- Removed setting of LEX_STRING() arguments in declaration (portability fix).
- Some trivial indentation/variable name changes.
- Some trivial code simplifications:
- Replaced some calls to alloc_root + memcpy to use
strmake_root()/strdup_root().
- Changed some calls from memdup() to strmake() (Safety fix)
- Simpler loops in client-simple.c
2007-05-10 11:59:39 +02:00
|
|
|
order_list.next= (uchar**) &order_list.first;
|
2005-06-07 12:11:36 +02:00
|
|
|
/* Set limit and offset to default values */
|
|
|
|
select_limit= 0; /* denotes the default limit = HA_POS_ERROR */
|
|
|
|
offset_limit= 0; /* denotes the default offset = 0 */
|
2003-07-03 01:30:52 +02:00
|
|
|
with_sum_func= 0;
|
2006-10-31 18:51:09 +01:00
|
|
|
is_correlated= 0;
|
2007-01-11 21:18:01 +01:00
|
|
|
cur_pos_in_select_list= UNDEF_POS;
|
|
|
|
non_agg_fields.empty();
|
2007-03-07 19:44:58 +01:00
|
|
|
cond_value= having_value= Item::COND_UNDEF;
|
2007-02-21 21:00:32 +01:00
|
|
|
inner_refs_list.empty();
|
2008-03-27 17:49:32 +01:00
|
|
|
full_group_by_flag= 0;
|
2002-05-06 23:04:16 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
st_select_lex structures linking
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* include on level down */
|
|
|
|
void st_select_lex_node::include_down(st_select_lex_node *upper)
|
|
|
|
{
|
|
|
|
if ((next= upper->slave))
|
|
|
|
next->prev= &next;
|
|
|
|
prev= &upper->slave;
|
|
|
|
upper->slave= this;
|
|
|
|
master= upper;
|
2002-12-15 21:01:09 +01:00
|
|
|
slave= 0;
|
2002-05-06 23:04:16 +02:00
|
|
|
}
|
|
|
|
|
2003-07-03 01:30:52 +02:00
|
|
|
/*
|
|
|
|
include on level down (but do not link)
|
2004-07-21 21:44:12 +02:00
|
|
|
|
2003-07-03 01:30:52 +02:00
|
|
|
SYNOPSYS
|
|
|
|
st_select_lex_node::include_standalone()
|
|
|
|
upper - reference on node underr which this node should be included
|
|
|
|
ref - references on reference on this node
|
|
|
|
*/
|
|
|
|
void st_select_lex_node::include_standalone(st_select_lex_node *upper,
|
|
|
|
st_select_lex_node **ref)
|
|
|
|
{
|
|
|
|
next= 0;
|
|
|
|
prev= ref;
|
|
|
|
master= upper;
|
|
|
|
slave= 0;
|
|
|
|
}
|
|
|
|
|
2002-05-06 23:04:16 +02:00
|
|
|
/* include neighbour (on same level) */
|
|
|
|
void st_select_lex_node::include_neighbour(st_select_lex_node *before)
|
|
|
|
{
|
|
|
|
if ((next= before->next))
|
|
|
|
next->prev= &next;
|
|
|
|
prev= &before->next;
|
|
|
|
before->next= this;
|
|
|
|
master= before->master;
|
2002-12-15 21:01:09 +01:00
|
|
|
slave= 0;
|
2002-05-06 23:04:16 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* including in global SELECT_LEX list */
|
|
|
|
void st_select_lex_node::include_global(st_select_lex_node **plink)
|
|
|
|
{
|
|
|
|
if ((link_next= *plink))
|
|
|
|
link_next->link_prev= &link_next;
|
|
|
|
link_prev= plink;
|
|
|
|
*plink= this;
|
|
|
|
}
|
|
|
|
|
|
|
|
//excluding from global list (internal function)
|
|
|
|
void st_select_lex_node::fast_exclude()
|
|
|
|
{
|
2002-12-28 00:01:05 +01:00
|
|
|
if (link_prev)
|
2002-05-06 23:04:16 +02:00
|
|
|
{
|
|
|
|
if ((*link_prev= link_next))
|
|
|
|
link_next->link_prev= link_prev;
|
|
|
|
}
|
2003-02-16 19:37:51 +01:00
|
|
|
// Remove slave structure
|
|
|
|
for (; slave; slave= slave->next)
|
|
|
|
slave->fast_exclude();
|
|
|
|
|
2002-05-06 23:04:16 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
excluding select_lex structure (except first (first select can't be
|
|
|
|
deleted, because it is most upper select))
|
|
|
|
*/
|
|
|
|
void st_select_lex_node::exclude()
|
|
|
|
{
|
|
|
|
//exclude from global list
|
|
|
|
fast_exclude();
|
|
|
|
//exclude from other structures
|
|
|
|
if ((*prev= next))
|
|
|
|
next->prev= prev;
|
|
|
|
/*
|
|
|
|
We do not need following statements, because prev pointer of first
|
|
|
|
list element point to master->slave
|
|
|
|
if (master->slave == this)
|
|
|
|
master->slave= next;
|
|
|
|
*/
|
|
|
|
}
|
2002-05-09 14:23:57 +02:00
|
|
|
|
2003-10-17 14:18:57 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
Exclude level of current unit from tree of SELECTs
|
|
|
|
|
|
|
|
SYNOPSYS
|
|
|
|
st_select_lex_unit::exclude_level()
|
|
|
|
|
|
|
|
NOTE: units which belong to current will be brought up on level of
|
|
|
|
currernt unit
|
|
|
|
*/
|
2002-11-28 18:29:26 +01:00
|
|
|
void st_select_lex_unit::exclude_level()
|
|
|
|
{
|
|
|
|
SELECT_LEX_UNIT *units= 0, **units_last= &units;
|
2002-12-28 00:01:05 +01:00
|
|
|
for (SELECT_LEX *sl= first_select(); sl; sl= sl->next_select())
|
2002-11-28 18:29:26 +01:00
|
|
|
{
|
2003-10-25 15:29:35 +02:00
|
|
|
// unlink current level from global SELECTs list
|
2002-11-28 18:29:26 +01:00
|
|
|
if (sl->link_prev && (*sl->link_prev= sl->link_next))
|
|
|
|
sl->link_next->link_prev= sl->link_prev;
|
2003-10-25 15:29:35 +02:00
|
|
|
|
|
|
|
// bring up underlay levels
|
2002-11-28 18:29:26 +01:00
|
|
|
SELECT_LEX_UNIT **last= 0;
|
|
|
|
for (SELECT_LEX_UNIT *u= sl->first_inner_unit(); u; u= u->next_unit())
|
2002-11-29 09:44:30 +01:00
|
|
|
{
|
|
|
|
u->master= master;
|
2002-11-28 18:29:26 +01:00
|
|
|
last= (SELECT_LEX_UNIT**)&(u->next);
|
2002-11-29 09:44:30 +01:00
|
|
|
}
|
2002-11-28 18:29:26 +01:00
|
|
|
if (last)
|
|
|
|
{
|
|
|
|
(*units_last)= sl->first_inner_unit();
|
|
|
|
units_last= last;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (units)
|
|
|
|
{
|
2003-10-25 15:29:35 +02:00
|
|
|
// include brought up levels in place of current
|
2002-11-28 18:29:26 +01:00
|
|
|
(*prev)= units;
|
|
|
|
(*units_last)= (SELECT_LEX_UNIT*)next;
|
2003-10-25 15:29:35 +02:00
|
|
|
if (next)
|
|
|
|
next->prev= (SELECT_LEX_NODE**)units_last;
|
|
|
|
units->prev= prev;
|
2002-11-28 18:29:26 +01:00
|
|
|
}
|
|
|
|
else
|
2003-10-25 15:29:35 +02:00
|
|
|
{
|
|
|
|
// exclude currect unit from list of nodes
|
2002-11-28 18:29:26 +01:00
|
|
|
(*prev)= next;
|
2003-10-25 15:29:35 +02:00
|
|
|
if (next)
|
|
|
|
next->prev= prev;
|
|
|
|
}
|
2002-11-28 18:29:26 +01:00
|
|
|
}
|
|
|
|
|
2003-10-17 14:18:57 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
Exclude subtree of current unit from tree of SELECTs
|
|
|
|
|
|
|
|
SYNOPSYS
|
|
|
|
st_select_lex_unit::exclude_tree()
|
|
|
|
*/
|
|
|
|
void st_select_lex_unit::exclude_tree()
|
|
|
|
{
|
|
|
|
for (SELECT_LEX *sl= first_select(); sl; sl= sl->next_select())
|
|
|
|
{
|
2003-10-25 15:29:35 +02:00
|
|
|
// unlink current level from global SELECTs list
|
2003-10-17 14:18:57 +02:00
|
|
|
if (sl->link_prev && (*sl->link_prev= sl->link_next))
|
|
|
|
sl->link_next->link_prev= sl->link_prev;
|
|
|
|
|
2003-10-25 15:29:35 +02:00
|
|
|
// unlink underlay levels
|
2003-10-17 14:18:57 +02:00
|
|
|
for (SELECT_LEX_UNIT *u= sl->first_inner_unit(); u; u= u->next_unit())
|
|
|
|
{
|
|
|
|
u->exclude_level();
|
|
|
|
}
|
|
|
|
}
|
2003-10-25 15:29:35 +02:00
|
|
|
// exclude currect unit from list of nodes
|
2003-10-17 14:18:57 +02:00
|
|
|
(*prev)= next;
|
2003-10-25 15:29:35 +02:00
|
|
|
if (next)
|
|
|
|
next->prev= prev;
|
2003-10-17 14:18:57 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2002-11-04 21:12:45 +01:00
|
|
|
/*
|
|
|
|
st_select_lex_node::mark_as_dependent mark all st_select_lex struct from
|
|
|
|
this to 'last' as dependent
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
last - pointer to last st_select_lex struct, before wich all
|
|
|
|
st_select_lex have to be marked as dependent
|
|
|
|
|
|
|
|
NOTE
|
|
|
|
'last' should be reachable from this st_select_lex_node
|
|
|
|
*/
|
|
|
|
|
2007-08-16 17:52:55 +02:00
|
|
|
void st_select_lex::mark_as_dependent(st_select_lex *last)
|
2002-11-04 21:12:45 +01:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
Mark all selects from resolved to 1 before select where was
|
|
|
|
found table as depended (of select where was found table)
|
|
|
|
*/
|
2003-07-03 01:30:52 +02:00
|
|
|
for (SELECT_LEX *s= this;
|
2003-11-02 15:31:22 +01:00
|
|
|
s && s != last;
|
2002-11-04 21:12:45 +01:00
|
|
|
s= s->outer_select())
|
2003-11-17 19:53:40 +01:00
|
|
|
if (!(s->uncacheable & UNCACHEABLE_DEPENDENT))
|
2002-11-04 21:12:45 +01:00
|
|
|
{
|
|
|
|
// Select is dependent of outer select
|
2007-01-19 09:17:28 +01:00
|
|
|
s->uncacheable= (s->uncacheable & ~UNCACHEABLE_UNITED) |
|
|
|
|
UNCACHEABLE_DEPENDENT;
|
2003-11-02 15:31:22 +01:00
|
|
|
SELECT_LEX_UNIT *munit= s->master_unit();
|
2007-01-19 09:17:28 +01:00
|
|
|
munit->uncacheable= (munit->uncacheable & ~UNCACHEABLE_UNITED) |
|
|
|
|
UNCACHEABLE_DEPENDENT;
|
|
|
|
for (SELECT_LEX *sl= munit->first_select(); sl ; sl= sl->next_select())
|
|
|
|
{
|
|
|
|
if (sl != s &&
|
|
|
|
!(sl->uncacheable & (UNCACHEABLE_DEPENDENT | UNCACHEABLE_UNITED)))
|
|
|
|
sl->uncacheable|= UNCACHEABLE_UNITED;
|
|
|
|
}
|
2002-11-04 21:12:45 +01:00
|
|
|
}
|
2006-10-31 18:51:09 +01:00
|
|
|
is_correlated= TRUE;
|
|
|
|
this->master_unit()->item->is_correlated= TRUE;
|
2002-11-04 21:12:45 +01:00
|
|
|
}
|
|
|
|
|
2002-10-30 12:18:52 +01:00
|
|
|
bool st_select_lex_node::set_braces(bool value) { return 1; }
|
|
|
|
bool st_select_lex_node::inc_in_sum_expr() { return 1; }
|
|
|
|
uint st_select_lex_node::get_in_sum_expr() { return 0; }
|
|
|
|
TABLE_LIST* st_select_lex_node::get_table_list() { return 0; }
|
|
|
|
List<Item>* st_select_lex_node::get_item_list() { return 0; }
|
2007-03-05 18:08:41 +01:00
|
|
|
TABLE_LIST *st_select_lex_node::add_table_to_list (THD *thd, Table_ident *table,
|
2002-10-30 12:18:52 +01:00
|
|
|
LEX_STRING *alias,
|
2003-01-09 21:42:31 +01:00
|
|
|
ulong table_join_options,
|
2002-10-30 12:18:52 +01:00
|
|
|
thr_lock_type flags,
|
2007-07-23 18:09:48 +02:00
|
|
|
List<Index_hint> *hints,
|
2003-07-16 21:30:49 +02:00
|
|
|
LEX_STRING *option)
|
2003-08-27 00:14:13 +02:00
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
2003-07-02 00:45:22 +02:00
|
|
|
ulong st_select_lex_node::get_table_join_options()
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
prohibit using LIMIT clause
|
|
|
|
*/
|
2003-07-03 01:30:52 +02:00
|
|
|
bool st_select_lex::test_limit()
|
2003-07-02 00:45:22 +02:00
|
|
|
{
|
2005-06-07 12:11:36 +02:00
|
|
|
if (select_limit != 0)
|
2003-07-02 00:45:22 +02:00
|
|
|
{
|
|
|
|
my_error(ER_NOT_SUPPORTED_YET, MYF(0),
|
2004-11-12 13:34:00 +01:00
|
|
|
"LIMIT & IN/ALL/ANY/SOME subquery");
|
2003-07-02 00:45:22 +02:00
|
|
|
return(1);
|
|
|
|
}
|
|
|
|
return(0);
|
|
|
|
}
|
2002-05-09 14:23:57 +02:00
|
|
|
|
2004-02-01 14:30:32 +01:00
|
|
|
|
2002-10-30 12:18:52 +01:00
|
|
|
st_select_lex_unit* st_select_lex_unit::master_unit()
|
|
|
|
{
|
|
|
|
return this;
|
|
|
|
}
|
|
|
|
|
2004-02-01 14:30:32 +01:00
|
|
|
|
2002-10-30 12:18:52 +01:00
|
|
|
st_select_lex* st_select_lex_unit::outer_select()
|
|
|
|
{
|
|
|
|
return (st_select_lex*) master;
|
|
|
|
}
|
|
|
|
|
2004-02-01 14:30:32 +01:00
|
|
|
|
2003-07-03 01:30:52 +02:00
|
|
|
bool st_select_lex::add_order_to_list(THD *thd, Item *item, bool asc)
|
2002-11-04 21:12:45 +01:00
|
|
|
{
|
2003-07-03 01:30:52 +02:00
|
|
|
return add_to_list(thd, order_list, item, asc);
|
2002-11-04 21:12:45 +01:00
|
|
|
}
|
2002-10-30 12:18:52 +01:00
|
|
|
|
2004-02-01 14:30:32 +01:00
|
|
|
|
2002-12-06 20:11:27 +01:00
|
|
|
bool st_select_lex::add_item_to_list(THD *thd, Item *item)
|
2002-10-30 12:18:52 +01:00
|
|
|
{
|
2004-05-20 01:02:49 +02:00
|
|
|
DBUG_ENTER("st_select_lex::add_item_to_list");
|
2006-11-27 00:47:38 +01:00
|
|
|
DBUG_PRINT("info", ("Item: 0x%lx", (long) item));
|
2004-05-20 01:02:49 +02:00
|
|
|
DBUG_RETURN(item_list.push_back(item));
|
2002-10-30 12:18:52 +01:00
|
|
|
}
|
|
|
|
|
2004-02-01 14:30:32 +01:00
|
|
|
|
2002-12-06 20:11:27 +01:00
|
|
|
bool st_select_lex::add_group_to_list(THD *thd, Item *item, bool asc)
|
2002-10-30 12:18:52 +01:00
|
|
|
{
|
2002-12-06 20:11:27 +01:00
|
|
|
return add_to_list(thd, group_list, item, asc);
|
2002-10-30 12:18:52 +01:00
|
|
|
}
|
|
|
|
|
2004-02-01 14:30:32 +01:00
|
|
|
|
2002-10-30 12:18:52 +01:00
|
|
|
bool st_select_lex::add_ftfunc_to_list(Item_func_match *func)
|
|
|
|
{
|
|
|
|
return !func || ftfunc_list->push_back(func); // end of memory?
|
|
|
|
}
|
|
|
|
|
2004-02-01 14:30:32 +01:00
|
|
|
|
2002-10-30 12:18:52 +01:00
|
|
|
st_select_lex_unit* st_select_lex::master_unit()
|
|
|
|
{
|
|
|
|
return (st_select_lex_unit*) master;
|
|
|
|
}
|
|
|
|
|
2004-02-01 14:30:32 +01:00
|
|
|
|
2002-10-30 12:18:52 +01:00
|
|
|
st_select_lex* st_select_lex::outer_select()
|
|
|
|
{
|
|
|
|
return (st_select_lex*) master->get_master();
|
|
|
|
}
|
|
|
|
|
2004-02-01 14:30:32 +01:00
|
|
|
|
2002-10-30 12:18:52 +01:00
|
|
|
bool st_select_lex::set_braces(bool value)
|
|
|
|
{
|
|
|
|
braces= value;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2004-02-01 14:30:32 +01:00
|
|
|
|
2002-10-30 12:18:52 +01:00
|
|
|
bool st_select_lex::inc_in_sum_expr()
|
|
|
|
{
|
|
|
|
in_sum_expr++;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2004-02-01 14:30:32 +01:00
|
|
|
|
2002-10-30 12:18:52 +01:00
|
|
|
uint st_select_lex::get_in_sum_expr()
|
|
|
|
{
|
|
|
|
return in_sum_expr;
|
|
|
|
}
|
|
|
|
|
2004-02-01 14:30:32 +01:00
|
|
|
|
2002-10-30 12:18:52 +01:00
|
|
|
TABLE_LIST* st_select_lex::get_table_list()
|
|
|
|
{
|
|
|
|
return (TABLE_LIST*) table_list.first;
|
|
|
|
}
|
|
|
|
|
|
|
|
List<Item>* st_select_lex::get_item_list()
|
|
|
|
{
|
|
|
|
return &item_list;
|
|
|
|
}
|
|
|
|
|
2003-01-09 21:42:31 +01:00
|
|
|
ulong st_select_lex::get_table_join_options()
|
|
|
|
{
|
|
|
|
return table_join_options;
|
|
|
|
}
|
|
|
|
|
2004-02-01 14:30:32 +01:00
|
|
|
|
2003-08-16 12:26:48 +02:00
|
|
|
bool st_select_lex::setup_ref_array(THD *thd, uint order_group_num)
|
|
|
|
{
|
|
|
|
if (ref_pointer_array)
|
|
|
|
return 0;
|
2004-02-12 02:10:26 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
We have to create array in prepared statement memory if it is
|
|
|
|
prepared statement
|
|
|
|
*/
|
2005-09-02 15:21:19 +02:00
|
|
|
Query_arena *arena= thd->stmt_arena;
|
2005-06-15 19:58:35 +02:00
|
|
|
return (ref_pointer_array=
|
2006-09-01 11:23:43 +02:00
|
|
|
(Item **)arena->alloc(sizeof(Item*) * (n_child_sum_items +
|
|
|
|
item_list.elements +
|
|
|
|
select_n_having_items +
|
2007-02-24 21:04:15 +01:00
|
|
|
select_n_where_fields +
|
2006-09-01 11:23:43 +02:00
|
|
|
order_group_num)*5)) == 0;
|
2003-08-16 12:26:48 +02:00
|
|
|
}
|
|
|
|
|
2004-02-01 14:30:32 +01:00
|
|
|
|
2008-02-22 11:30:33 +01:00
|
|
|
void st_select_lex_unit::print(String *str, enum_query_type query_type)
|
2003-10-16 14:54:47 +02:00
|
|
|
{
|
2005-08-15 21:05:05 +02:00
|
|
|
bool union_all= !union_distinct;
|
2003-10-16 14:54:47 +02:00
|
|
|
for (SELECT_LEX *sl= first_select(); sl; sl= sl->next_select())
|
|
|
|
{
|
|
|
|
if (sl != first_select())
|
|
|
|
{
|
2005-11-20 19:47:07 +01:00
|
|
|
str->append(STRING_WITH_LEN(" union "));
|
2005-08-15 21:05:05 +02:00
|
|
|
if (union_all)
|
2005-11-20 19:47:07 +01:00
|
|
|
str->append(STRING_WITH_LEN("all "));
|
2005-08-15 21:05:05 +02:00
|
|
|
else if (union_distinct == sl)
|
2005-08-22 00:13:37 +02:00
|
|
|
union_all= TRUE;
|
2003-10-16 14:54:47 +02:00
|
|
|
}
|
|
|
|
if (sl->braces)
|
|
|
|
str->append('(');
|
2008-02-22 11:30:33 +01:00
|
|
|
sl->print(thd, str, query_type);
|
2003-10-16 14:54:47 +02:00
|
|
|
if (sl->braces)
|
|
|
|
str->append(')');
|
|
|
|
}
|
|
|
|
if (fake_select_lex == global_parameters)
|
|
|
|
{
|
|
|
|
if (fake_select_lex->order_list.elements)
|
|
|
|
{
|
2005-11-20 19:47:07 +01:00
|
|
|
str->append(STRING_WITH_LEN(" order by "));
|
2008-02-22 11:30:33 +01:00
|
|
|
fake_select_lex->print_order(
|
|
|
|
str,
|
|
|
|
(ORDER *) fake_select_lex->order_list.first,
|
|
|
|
query_type);
|
2003-10-16 14:54:47 +02:00
|
|
|
}
|
2008-02-22 11:30:33 +01:00
|
|
|
fake_select_lex->print_limit(thd, str, query_type);
|
2003-10-16 14:54:47 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2008-02-22 11:30:33 +01:00
|
|
|
void st_select_lex::print_order(String *str,
|
|
|
|
ORDER *order,
|
|
|
|
enum_query_type query_type)
|
2003-10-16 14:54:47 +02:00
|
|
|
{
|
|
|
|
for (; order; order= order->next)
|
|
|
|
{
|
2004-08-31 10:58:45 +02:00
|
|
|
if (order->counter_used)
|
|
|
|
{
|
|
|
|
char buffer[20];
|
2009-02-13 17:41:47 +01:00
|
|
|
size_t length= my_snprintf(buffer, 20, "%d", order->counter);
|
|
|
|
str->append(buffer, (uint) length);
|
2004-08-31 10:58:45 +02:00
|
|
|
}
|
|
|
|
else
|
2008-02-22 11:30:33 +01:00
|
|
|
(*order->item)->print(str, query_type);
|
2003-10-16 14:54:47 +02:00
|
|
|
if (!order->asc)
|
2005-11-20 19:47:07 +01:00
|
|
|
str->append(STRING_WITH_LEN(" desc"));
|
2003-10-16 14:54:47 +02:00
|
|
|
if (order->next)
|
|
|
|
str->append(',');
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2004-02-01 14:30:32 +01:00
|
|
|
|
2008-02-22 11:30:33 +01:00
|
|
|
void st_select_lex::print_limit(THD *thd,
|
|
|
|
String *str,
|
|
|
|
enum_query_type query_type)
|
2003-10-16 14:54:47 +02:00
|
|
|
{
|
2004-08-23 12:19:59 +02:00
|
|
|
SELECT_LEX_UNIT *unit= master_unit();
|
|
|
|
Item_subselect *item= unit->item;
|
|
|
|
if (item && unit->global_parameters == this &&
|
2004-07-16 00:15:55 +02:00
|
|
|
(item->substype() == Item_subselect::EXISTS_SUBS ||
|
|
|
|
item->substype() == Item_subselect::IN_SUBS ||
|
|
|
|
item->substype() == Item_subselect::ALL_SUBS))
|
|
|
|
{
|
2005-06-07 12:11:36 +02:00
|
|
|
DBUG_ASSERT(!item->fixed ||
|
2008-12-16 13:12:22 +01:00
|
|
|
(select_limit->val_int() == LL(1) && offset_limit == 0));
|
2004-07-16 00:15:55 +02:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2004-05-05 20:21:41 +02:00
|
|
|
if (explicit_limit)
|
2003-10-16 14:54:47 +02:00
|
|
|
{
|
2005-11-20 19:47:07 +01:00
|
|
|
str->append(STRING_WITH_LEN(" limit "));
|
2003-10-16 14:54:47 +02:00
|
|
|
if (offset_limit)
|
|
|
|
{
|
2008-02-22 11:30:33 +01:00
|
|
|
offset_limit->print(str, query_type);
|
2003-10-16 14:54:47 +02:00
|
|
|
str->append(',');
|
|
|
|
}
|
2008-02-22 11:30:33 +01:00
|
|
|
select_limit->print(str, query_type);
|
2003-10-16 14:54:47 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
/**
|
|
|
|
@brief Restore the LEX and THD in case of a parse error.
|
|
|
|
|
|
|
|
This is a clean up call that is invoked by the Bison generated
|
|
|
|
parser before returning an error from MYSQLparse. If your
|
|
|
|
semantic actions manipulate with the global thread state (which
|
|
|
|
is a very bad practice and should not normally be employed) and
|
|
|
|
need a clean-up in case of error, and you can not use %destructor
|
|
|
|
rule in the grammar file itself, this function should be used
|
|
|
|
to implement the clean up.
|
|
|
|
*/
|
|
|
|
|
2009-10-14 13:14:58 +02:00
|
|
|
void LEX::cleanup_lex_after_parse_error(THD *thd)
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
Delete sphead for the side effect of restoring of the original
|
|
|
|
LEX state, thd->lex, thd->mem_root and thd->free_list if they
|
|
|
|
were replaced when parsing stored procedure statements. We
|
|
|
|
will never use sphead object after a parse error, so it's okay
|
|
|
|
to delete it only for the sake of the side effect.
|
|
|
|
TODO: make this functionality explicit in sp_head class.
|
|
|
|
Sic: we must nullify the member of the main lex, not the
|
|
|
|
current one that will be thrown away
|
|
|
|
*/
|
2007-03-07 12:03:44 +01:00
|
|
|
if (thd->lex->sphead)
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
{
|
|
|
|
delete thd->lex->sphead;
|
|
|
|
thd->lex->sphead= NULL;
|
|
|
|
}
|
|
|
|
}
|
2004-07-16 00:15:55 +02:00
|
|
|
|
2006-05-30 07:45:23 +02:00
|
|
|
/*
|
|
|
|
Initialize (or reset) Query_tables_list object.
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
reset_query_tables_list()
|
|
|
|
init TRUE - we should perform full initialization of object with
|
|
|
|
allocating needed memory
|
|
|
|
FALSE - object is already initialized so we should only reset
|
|
|
|
its state so it can be used for parsing/processing
|
|
|
|
of new statement
|
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
This method initializes Query_tables_list so it can be used as part
|
|
|
|
of LEX object for parsing/processing of statement. One can also use
|
|
|
|
this method to reset state of already initialized Query_tables_list
|
|
|
|
so it can be used for processing of new statement.
|
|
|
|
*/
|
|
|
|
|
|
|
|
void Query_tables_list::reset_query_tables_list(bool init)
|
|
|
|
{
|
2010-04-28 12:04:11 +02:00
|
|
|
sql_command= SQLCOM_END;
|
2007-03-02 17:43:45 +01:00
|
|
|
if (!init && query_tables)
|
|
|
|
{
|
|
|
|
TABLE_LIST *table= query_tables;
|
|
|
|
for (;;)
|
|
|
|
{
|
|
|
|
delete table->view;
|
|
|
|
if (query_tables_last == &table->next_global ||
|
|
|
|
!(table= table->next_global))
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2006-05-30 07:45:23 +02:00
|
|
|
query_tables= 0;
|
|
|
|
query_tables_last= &query_tables;
|
|
|
|
query_tables_own_last= 0;
|
|
|
|
if (init)
|
2006-11-01 13:41:48 +01:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
We delay real initialization of hash (and therefore related
|
|
|
|
memory allocation) until first insertion into this hash.
|
|
|
|
*/
|
2009-10-14 18:37:38 +02:00
|
|
|
my_hash_clear(&sroutines);
|
2006-11-01 13:41:48 +01:00
|
|
|
}
|
2006-05-30 07:45:23 +02:00
|
|
|
else if (sroutines.records)
|
2006-11-01 13:41:48 +01:00
|
|
|
{
|
|
|
|
/* Non-zero sroutines.records means that hash was initialized. */
|
2006-05-30 07:45:23 +02:00
|
|
|
my_hash_reset(&sroutines);
|
2006-11-01 13:41:48 +01:00
|
|
|
}
|
2006-05-30 07:45:23 +02:00
|
|
|
sroutines_list.empty();
|
|
|
|
sroutines_list_own_last= sroutines_list.next;
|
|
|
|
sroutines_list_own_elements= 0;
|
2007-05-14 14:45:38 +02:00
|
|
|
binlog_stmt_flags= 0;
|
2006-05-30 07:45:23 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
Destroy Query_tables_list object with freeing all resources used by it.
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
destroy_query_tables_list()
|
|
|
|
*/
|
|
|
|
|
|
|
|
void Query_tables_list::destroy_query_tables_list()
|
|
|
|
{
|
2009-10-14 18:37:38 +02:00
|
|
|
my_hash_free(&sroutines);
|
2006-05-30 07:45:23 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2005-07-09 19:51:59 +02:00
|
|
|
/*
|
|
|
|
Initialize LEX object.
|
|
|
|
|
|
|
|
SYNOPSIS
|
2009-10-14 13:14:58 +02:00
|
|
|
LEX::LEX()
|
2005-07-09 19:51:59 +02:00
|
|
|
|
|
|
|
NOTE
|
|
|
|
LEX object initialized with this constructor can be used as part of
|
|
|
|
THD object for which one can safely call open_tables(), lock_tables()
|
|
|
|
and close_thread_tables() functions. But it is not yet ready for
|
|
|
|
statement parsing. On should use lex_start() function to prepare LEX
|
|
|
|
for this.
|
|
|
|
*/
|
|
|
|
|
2009-10-14 13:14:58 +02:00
|
|
|
LEX::LEX()
|
2010-04-28 12:04:11 +02:00
|
|
|
:result(0), option_type(OPT_DEFAULT), is_lex_started(0)
|
2005-07-09 19:51:59 +02:00
|
|
|
{
|
2007-03-23 18:14:46 +01:00
|
|
|
|
2007-03-02 17:43:45 +01:00
|
|
|
my_init_dynamic_array2(&plugins, sizeof(plugin_ref),
|
|
|
|
plugins_static_buffer,
|
|
|
|
INITIAL_LEX_PLUGIN_LIST_SIZE,
|
|
|
|
INITIAL_LEX_PLUGIN_LIST_SIZE);
|
2006-05-30 07:45:23 +02:00
|
|
|
reset_query_tables_list(TRUE);
|
2005-07-09 19:51:59 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2004-07-16 00:15:55 +02:00
|
|
|
/*
|
2004-10-07 00:45:06 +02:00
|
|
|
Check whether the merging algorithm can be used on this VIEW
|
2004-07-16 00:15:55 +02:00
|
|
|
|
|
|
|
SYNOPSIS
|
2009-10-14 13:14:58 +02:00
|
|
|
LEX::can_be_merged()
|
2004-07-16 00:15:55 +02:00
|
|
|
|
2004-10-07 00:45:06 +02:00
|
|
|
DESCRIPTION
|
2004-10-07 21:54:31 +02:00
|
|
|
We can apply merge algorithm if it is single SELECT view with
|
|
|
|
subqueries only in WHERE clause (we do not count SELECTs of underlying
|
|
|
|
views, and second level subqueries) and we have not grpouping, ordering,
|
2004-10-07 00:45:06 +02:00
|
|
|
HAVING clause, aggregate functions, DISTINCT clause, LIMIT clause and
|
|
|
|
several underlying tables.
|
|
|
|
|
2004-07-16 00:15:55 +02:00
|
|
|
RETURN
|
|
|
|
FALSE - only temporary table algorithm can be used
|
|
|
|
TRUE - merge algorithm can be used
|
|
|
|
*/
|
|
|
|
|
2009-10-14 13:14:58 +02:00
|
|
|
bool LEX::can_be_merged()
|
2004-07-16 00:15:55 +02:00
|
|
|
{
|
|
|
|
// TODO: do not forget implement case when select_lex.table_list.elements==0
|
|
|
|
|
|
|
|
/* find non VIEW subqueries/unions */
|
2004-10-07 21:54:31 +02:00
|
|
|
bool selects_allow_merge= select_lex.next_select() == 0;
|
|
|
|
if (selects_allow_merge)
|
|
|
|
{
|
2006-12-14 23:51:37 +01:00
|
|
|
for (SELECT_LEX_UNIT *tmp_unit= select_lex.first_inner_unit();
|
|
|
|
tmp_unit;
|
|
|
|
tmp_unit= tmp_unit->next_unit())
|
2004-10-07 21:54:31 +02:00
|
|
|
{
|
2006-12-14 23:51:37 +01:00
|
|
|
if (tmp_unit->first_select()->parent_lex == this &&
|
|
|
|
(tmp_unit->item == 0 ||
|
|
|
|
(tmp_unit->item->place() != IN_WHERE &&
|
|
|
|
tmp_unit->item->place() != IN_ON)))
|
2004-10-07 21:54:31 +02:00
|
|
|
{
|
|
|
|
selects_allow_merge= 0;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return (selects_allow_merge &&
|
2004-07-16 00:15:55 +02:00
|
|
|
select_lex.group_list.elements == 0 &&
|
|
|
|
select_lex.having == 0 &&
|
2004-08-26 13:34:56 +02:00
|
|
|
select_lex.with_sum_func == 0 &&
|
2004-09-14 18:28:29 +02:00
|
|
|
select_lex.table_list.elements >= 1 &&
|
2004-07-16 00:15:55 +02:00
|
|
|
!(select_lex.options & SELECT_DISTINCT) &&
|
2005-06-07 12:11:36 +02:00
|
|
|
select_lex.select_limit == 0);
|
2004-07-16 00:15:55 +02:00
|
|
|
}
|
|
|
|
|
2004-10-07 00:45:06 +02:00
|
|
|
|
2004-07-16 00:15:55 +02:00
|
|
|
/*
|
2004-08-24 21:51:23 +02:00
|
|
|
check if command can use VIEW with MERGE algorithm (for top VIEWs)
|
2004-07-16 00:15:55 +02:00
|
|
|
|
|
|
|
SYNOPSIS
|
2009-10-14 13:14:58 +02:00
|
|
|
LEX::can_use_merged()
|
2004-07-16 00:15:55 +02:00
|
|
|
|
2004-10-07 00:45:06 +02:00
|
|
|
DESCRIPTION
|
|
|
|
Only listed here commands can use merge algorithm in top level
|
|
|
|
SELECT_LEX (for subqueries will be used merge algorithm if
|
2009-10-14 13:14:58 +02:00
|
|
|
LEX::can_not_use_merged() is not TRUE).
|
2004-10-07 00:45:06 +02:00
|
|
|
|
2004-07-16 00:15:55 +02:00
|
|
|
RETURN
|
|
|
|
FALSE - command can't use merged VIEWs
|
|
|
|
TRUE - VIEWs with MERGE algorithms can be used
|
|
|
|
*/
|
|
|
|
|
2009-10-14 13:14:58 +02:00
|
|
|
bool LEX::can_use_merged()
|
2004-07-16 00:15:55 +02:00
|
|
|
{
|
|
|
|
switch (sql_command)
|
|
|
|
{
|
|
|
|
case SQLCOM_SELECT:
|
|
|
|
case SQLCOM_CREATE_TABLE:
|
|
|
|
case SQLCOM_UPDATE:
|
|
|
|
case SQLCOM_UPDATE_MULTI:
|
|
|
|
case SQLCOM_DELETE:
|
|
|
|
case SQLCOM_DELETE_MULTI:
|
|
|
|
case SQLCOM_INSERT:
|
|
|
|
case SQLCOM_INSERT_SELECT:
|
|
|
|
case SQLCOM_REPLACE:
|
|
|
|
case SQLCOM_REPLACE_SELECT:
|
2004-10-21 20:53:27 +02:00
|
|
|
case SQLCOM_LOAD:
|
2004-07-16 00:15:55 +02:00
|
|
|
return TRUE;
|
|
|
|
default:
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2004-08-24 21:51:23 +02:00
|
|
|
/*
|
2004-10-07 00:45:06 +02:00
|
|
|
Check if command can't use merged views in any part of command
|
2004-08-24 21:51:23 +02:00
|
|
|
|
|
|
|
SYNOPSIS
|
2009-10-14 13:14:58 +02:00
|
|
|
LEX::can_not_use_merged()
|
2004-08-24 21:51:23 +02:00
|
|
|
|
2004-10-07 00:45:06 +02:00
|
|
|
DESCRIPTION
|
|
|
|
Temporary table algorithm will be used on all SELECT levels for queries
|
2009-10-14 13:14:58 +02:00
|
|
|
listed here (see also LEX::can_use_merged()).
|
2004-10-07 00:45:06 +02:00
|
|
|
|
2004-08-24 21:51:23 +02:00
|
|
|
RETURN
|
|
|
|
FALSE - command can't use merged VIEWs
|
|
|
|
TRUE - VIEWs with MERGE algorithms can be used
|
|
|
|
*/
|
|
|
|
|
2009-10-14 13:14:58 +02:00
|
|
|
bool LEX::can_not_use_merged()
|
2004-08-24 21:51:23 +02:00
|
|
|
{
|
|
|
|
switch (sql_command)
|
|
|
|
{
|
|
|
|
case SQLCOM_CREATE_VIEW:
|
|
|
|
case SQLCOM_SHOW_CREATE:
|
2005-02-16 11:00:03 +01:00
|
|
|
/*
|
|
|
|
SQLCOM_SHOW_FIELDS is necessary to make
|
|
|
|
information schema tables working correctly with views.
|
|
|
|
see get_schema_tables_result function
|
|
|
|
*/
|
|
|
|
case SQLCOM_SHOW_FIELDS:
|
2004-08-24 21:51:23 +02:00
|
|
|
return TRUE;
|
|
|
|
default:
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2004-07-16 00:15:55 +02:00
|
|
|
/*
|
|
|
|
Detect that we need only table structure of derived table/view
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
only_view_structure()
|
|
|
|
|
|
|
|
RETURN
|
|
|
|
TRUE yes, we need only structure
|
|
|
|
FALSE no, we need data
|
|
|
|
*/
|
2004-11-24 18:48:30 +01:00
|
|
|
|
2009-10-14 13:14:58 +02:00
|
|
|
bool LEX::only_view_structure()
|
2004-07-16 00:15:55 +02:00
|
|
|
{
|
2005-07-01 06:05:42 +02:00
|
|
|
switch (sql_command) {
|
2004-07-16 00:15:55 +02:00
|
|
|
case SQLCOM_SHOW_CREATE:
|
|
|
|
case SQLCOM_SHOW_TABLES:
|
|
|
|
case SQLCOM_SHOW_FIELDS:
|
|
|
|
case SQLCOM_REVOKE_ALL:
|
|
|
|
case SQLCOM_REVOKE:
|
|
|
|
case SQLCOM_GRANT:
|
|
|
|
case SQLCOM_CREATE_VIEW:
|
|
|
|
return TRUE;
|
|
|
|
default:
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2004-11-24 18:48:30 +01:00
|
|
|
/*
|
|
|
|
Should Items_ident be printed correctly
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
need_correct_ident()
|
|
|
|
|
|
|
|
RETURN
|
|
|
|
TRUE yes, we need only structure
|
|
|
|
FALSE no, we need data
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
2009-10-14 13:14:58 +02:00
|
|
|
bool LEX::need_correct_ident()
|
2004-11-24 18:48:30 +01:00
|
|
|
{
|
|
|
|
switch(sql_command)
|
|
|
|
{
|
|
|
|
case SQLCOM_SHOW_CREATE:
|
|
|
|
case SQLCOM_SHOW_TABLES:
|
|
|
|
case SQLCOM_CREATE_VIEW:
|
|
|
|
return TRUE;
|
|
|
|
default:
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2005-07-01 06:05:42 +02:00
|
|
|
/*
|
|
|
|
Get effective type of CHECK OPTION for given view
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
get_effective_with_check()
|
|
|
|
view given view
|
|
|
|
|
|
|
|
NOTE
|
|
|
|
It have not sense to set CHECK OPTION for SELECT satement or subqueries,
|
|
|
|
so we do not.
|
|
|
|
|
|
|
|
RETURN
|
|
|
|
VIEW_CHECK_NONE no need CHECK OPTION
|
|
|
|
VIEW_CHECK_LOCAL CHECK OPTION LOCAL
|
|
|
|
VIEW_CHECK_CASCADED CHECK OPTION CASCADED
|
|
|
|
*/
|
|
|
|
|
2009-10-14 13:14:58 +02:00
|
|
|
uint8 LEX::get_effective_with_check(TABLE_LIST *view)
|
2005-07-01 06:05:42 +02:00
|
|
|
{
|
|
|
|
if (view->select_lex->master_unit() == &unit &&
|
|
|
|
which_check_option_applicable())
|
|
|
|
return (uint8)view->with_check;
|
|
|
|
return VIEW_CHECK_NONE;
|
|
|
|
}
|
|
|
|
|
2004-11-24 18:48:30 +01:00
|
|
|
|
2007-07-05 09:34:04 +02:00
|
|
|
/**
|
|
|
|
This method should be called only during parsing.
|
|
|
|
It is aware of compound statements (stored routine bodies)
|
|
|
|
and will initialize the destination with the default
|
|
|
|
database of the stored routine, rather than the default
|
|
|
|
database of the connection it is parsed in.
|
|
|
|
E.g. if one has no current database selected, or current database
|
|
|
|
set to 'bar' and then issues:
|
|
|
|
|
|
|
|
CREATE PROCEDURE foo.p1() BEGIN SELECT * FROM t1 END//
|
|
|
|
|
|
|
|
t1 is meant to refer to foo.t1, not to bar.t1.
|
|
|
|
|
|
|
|
This method is needed to support this rule.
|
|
|
|
|
|
|
|
@return TRUE in case of error (parsing should be aborted, FALSE in
|
|
|
|
case of success
|
|
|
|
*/
|
|
|
|
|
|
|
|
bool
|
2009-10-14 13:14:58 +02:00
|
|
|
LEX::copy_db_to(char **p_db, size_t *p_db_length) const
|
2007-07-05 09:34:04 +02:00
|
|
|
{
|
|
|
|
if (sphead)
|
|
|
|
{
|
|
|
|
DBUG_ASSERT(sphead->m_db.str && sphead->m_db.length);
|
|
|
|
/*
|
|
|
|
It is safe to assign the string by-pointer, both sphead and
|
|
|
|
its statements reside in the same memory root.
|
|
|
|
*/
|
|
|
|
*p_db= sphead->m_db.str;
|
|
|
|
if (p_db_length)
|
|
|
|
*p_db_length= sphead->m_db.length;
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
return thd->copy_db_to(p_db, p_db_length);
|
|
|
|
}
|
|
|
|
|
2004-03-29 21:40:49 +02:00
|
|
|
/*
|
|
|
|
initialize limit counters
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
st_select_lex_unit::set_limit()
|
|
|
|
values - SELECT_LEX with initial values for counters
|
|
|
|
*/
|
2004-07-16 00:15:55 +02:00
|
|
|
|
2007-08-16 17:52:55 +02:00
|
|
|
void st_select_lex_unit::set_limit(st_select_lex *sl)
|
2003-11-21 20:19:56 +01:00
|
|
|
{
|
2005-06-18 01:55:42 +02:00
|
|
|
ha_rows select_limit_val;
|
2007-09-19 16:47:52 +02:00
|
|
|
ulonglong val;
|
2005-06-07 12:11:36 +02:00
|
|
|
|
2005-09-02 15:21:19 +02:00
|
|
|
DBUG_ASSERT(! thd->stmt_arena->is_stmt_prepare());
|
2007-09-19 16:47:52 +02:00
|
|
|
val= sl->select_limit ? sl->select_limit->val_uint() : HA_POS_ERROR;
|
|
|
|
select_limit_val= (ha_rows)val;
|
|
|
|
#ifndef BIG_TABLES
|
2008-10-15 23:34:51 +02:00
|
|
|
/*
|
2007-09-19 16:47:52 +02:00
|
|
|
Check for overflow : ha_rows can be smaller then ulonglong if
|
|
|
|
BIG_TABLES is off.
|
|
|
|
*/
|
|
|
|
if (val != (ulonglong)select_limit_val)
|
|
|
|
select_limit_val= HA_POS_ERROR;
|
|
|
|
#endif
|
2008-10-15 23:34:51 +02:00
|
|
|
val= sl->offset_limit ? sl->offset_limit->val_uint() : ULL(0);
|
|
|
|
offset_limit_cnt= (ha_rows)val;
|
|
|
|
#ifndef BIG_TABLES
|
|
|
|
/* Check for truncation. */
|
|
|
|
if (val != (ulonglong)offset_limit_cnt)
|
|
|
|
offset_limit_cnt= HA_POS_ERROR;
|
|
|
|
#endif
|
2005-06-07 12:11:36 +02:00
|
|
|
select_limit_cnt= select_limit_val + offset_limit_cnt;
|
|
|
|
if (select_limit_cnt < select_limit_val)
|
2003-11-21 20:19:56 +01:00
|
|
|
select_limit_cnt= HA_POS_ERROR; // no limit
|
|
|
|
}
|
|
|
|
|
2004-04-10 00:14:32 +02:00
|
|
|
|
A fix and a test case for Bug#26141 mixing table types in trigger
causes full table lock on innodb table.
Also fixes Bug#28502 Triggers that update another innodb table
will block on X lock unnecessarily (duplciate).
Code review fixes.
Both bugs' synopses are misleading: InnoDB table is
not X locked. The statements, however, cannot proceed concurrently,
but this happens due to lock conflicts for tables used in triggers,
not for the InnoDB table.
If a user had an InnoDB table, and two triggers, AFTER UPDATE and
AFTER INSERT, competing for different resources (e.g. two distinct
MyISAM tables), then these two triggers would not be able to execute
concurrently. Moreover, INSERTS/UPDATES of the InnoDB table would
not be able to run concurrently.
The problem had other side-effects (see respective bug reports).
This behavior was a consequence of a shortcoming of the pre-locking
algorithm, which would not distinguish between different DML operations
(e.g. INSERT and DELETE) and pre-lock all the tables
that are used by any trigger defined on the subject table.
The idea of the fix is to extend the pre-locking algorithm to keep track,
for each table, what DML operation it is used for and not
load triggers that are known to never be fired.
2007-07-12 20:26:41 +02:00
|
|
|
/**
|
2007-07-27 16:56:29 +02:00
|
|
|
@brief Set the initial purpose of this TABLE_LIST object in the list of used
|
|
|
|
tables.
|
|
|
|
|
|
|
|
We need to track this information on table-by-table basis, since when this
|
|
|
|
table becomes an element of the pre-locked list, it's impossible to identify
|
|
|
|
which SQL sub-statement it has been originally used in.
|
|
|
|
|
|
|
|
E.g.:
|
|
|
|
|
|
|
|
User request: SELECT * FROM t1 WHERE f1();
|
|
|
|
FUNCTION f1(): DELETE FROM t2; RETURN 1;
|
|
|
|
BEFORE DELETE trigger on t2: INSERT INTO t3 VALUES (old.a);
|
|
|
|
|
|
|
|
For this user request, the pre-locked list will contain t1, t2, t3
|
|
|
|
table elements, each needed for different DML.
|
|
|
|
|
|
|
|
The trigger event map is updated to reflect INSERT, UPDATE, DELETE,
|
|
|
|
REPLACE, LOAD DATA, CREATE TABLE .. SELECT, CREATE TABLE ..
|
|
|
|
REPLACE SELECT statements, and additionally ON DUPLICATE KEY UPDATE
|
|
|
|
clause.
|
A fix and a test case for Bug#26141 mixing table types in trigger
causes full table lock on innodb table.
Also fixes Bug#28502 Triggers that update another innodb table
will block on X lock unnecessarily (duplciate).
Code review fixes.
Both bugs' synopses are misleading: InnoDB table is
not X locked. The statements, however, cannot proceed concurrently,
but this happens due to lock conflicts for tables used in triggers,
not for the InnoDB table.
If a user had an InnoDB table, and two triggers, AFTER UPDATE and
AFTER INSERT, competing for different resources (e.g. two distinct
MyISAM tables), then these two triggers would not be able to execute
concurrently. Moreover, INSERTS/UPDATES of the InnoDB table would
not be able to run concurrently.
The problem had other side-effects (see respective bug reports).
This behavior was a consequence of a shortcoming of the pre-locking
algorithm, which would not distinguish between different DML operations
(e.g. INSERT and DELETE) and pre-lock all the tables
that are used by any trigger defined on the subject table.
The idea of the fix is to extend the pre-locking algorithm to keep track,
for each table, what DML operation it is used for and not
load triggers that are known to never be fired.
2007-07-12 20:26:41 +02:00
|
|
|
*/
|
|
|
|
|
2009-10-14 13:14:58 +02:00
|
|
|
void LEX::set_trg_event_type_for_tables()
|
A fix and a test case for Bug#26141 mixing table types in trigger
causes full table lock on innodb table.
Also fixes Bug#28502 Triggers that update another innodb table
will block on X lock unnecessarily (duplciate).
Code review fixes.
Both bugs' synopses are misleading: InnoDB table is
not X locked. The statements, however, cannot proceed concurrently,
but this happens due to lock conflicts for tables used in triggers,
not for the InnoDB table.
If a user had an InnoDB table, and two triggers, AFTER UPDATE and
AFTER INSERT, competing for different resources (e.g. two distinct
MyISAM tables), then these two triggers would not be able to execute
concurrently. Moreover, INSERTS/UPDATES of the InnoDB table would
not be able to run concurrently.
The problem had other side-effects (see respective bug reports).
This behavior was a consequence of a shortcoming of the pre-locking
algorithm, which would not distinguish between different DML operations
(e.g. INSERT and DELETE) and pre-lock all the tables
that are used by any trigger defined on the subject table.
The idea of the fix is to extend the pre-locking algorithm to keep track,
for each table, what DML operation it is used for and not
load triggers that are known to never be fired.
2007-07-12 20:26:41 +02:00
|
|
|
{
|
2007-07-27 16:56:29 +02:00
|
|
|
uint8 new_trg_event_map= 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
Some auxiliary operations
|
|
|
|
(e.g. GRANT processing) create TABLE_LIST instances outside
|
|
|
|
the parser. Additionally, some commands (e.g. OPTIMIZE) change
|
|
|
|
the lock type for a table only after parsing is done. Luckily,
|
|
|
|
these do not fire triggers and do not need to pre-load them.
|
|
|
|
For these TABLE_LISTs set_trg_event_type is never called, and
|
|
|
|
trg_event_map is always empty. That means that the pre-locking
|
|
|
|
algorithm will ignore triggers defined on these tables, if
|
|
|
|
any, and the execution will either fail with an assert in
|
|
|
|
sql_trigger.cc or with an error that a used table was not
|
|
|
|
pre-locked, in case of a production build.
|
|
|
|
|
|
|
|
TODO: this usage pattern creates unnecessary module dependencies
|
|
|
|
and should be rewritten to go through the parser.
|
|
|
|
Table list instances created outside the parser in most cases
|
|
|
|
refer to mysql.* system tables. It is not allowed to have
|
|
|
|
a trigger on a system table, but keeping track of
|
|
|
|
initialization provides extra safety in case this limitation
|
|
|
|
is circumvented.
|
|
|
|
*/
|
|
|
|
|
|
|
|
switch (sql_command) {
|
|
|
|
case SQLCOM_LOCK_TABLES:
|
|
|
|
/*
|
|
|
|
On a LOCK TABLE, all triggers must be pre-loaded for this TABLE_LIST
|
|
|
|
when opening an associated TABLE.
|
|
|
|
*/
|
|
|
|
new_trg_event_map= static_cast<uint8>
|
|
|
|
(1 << static_cast<int>(TRG_EVENT_INSERT)) |
|
|
|
|
static_cast<uint8>
|
|
|
|
(1 << static_cast<int>(TRG_EVENT_UPDATE)) |
|
|
|
|
static_cast<uint8>
|
|
|
|
(1 << static_cast<int>(TRG_EVENT_DELETE));
|
|
|
|
break;
|
|
|
|
/*
|
|
|
|
Basic INSERT. If there is an additional ON DUPLIATE KEY UPDATE
|
|
|
|
clause, it will be handled later in this method.
|
|
|
|
*/
|
|
|
|
case SQLCOM_INSERT: /* fall through */
|
|
|
|
case SQLCOM_INSERT_SELECT:
|
|
|
|
/*
|
|
|
|
LOAD DATA ... INFILE is expected to fire BEFORE/AFTER INSERT
|
|
|
|
triggers.
|
|
|
|
If the statement also has REPLACE clause, it will be
|
|
|
|
handled later in this method.
|
|
|
|
*/
|
|
|
|
case SQLCOM_LOAD: /* fall through */
|
|
|
|
/*
|
|
|
|
REPLACE is semantically equivalent to INSERT. In case
|
|
|
|
of a primary or unique key conflict, it deletes the old
|
|
|
|
record and inserts a new one. So we also may need to
|
|
|
|
fire ON DELETE triggers. This functionality is handled
|
|
|
|
later in this method.
|
|
|
|
*/
|
|
|
|
case SQLCOM_REPLACE: /* fall through */
|
|
|
|
case SQLCOM_REPLACE_SELECT:
|
|
|
|
/*
|
|
|
|
CREATE TABLE ... SELECT defaults to INSERT if the table or
|
|
|
|
view already exists. REPLACE option of CREATE TABLE ...
|
|
|
|
REPLACE SELECT is handled later in this method.
|
|
|
|
*/
|
|
|
|
case SQLCOM_CREATE_TABLE:
|
|
|
|
new_trg_event_map|= static_cast<uint8>
|
|
|
|
(1 << static_cast<int>(TRG_EVENT_INSERT));
|
|
|
|
break;
|
|
|
|
/* Basic update and multi-update */
|
|
|
|
case SQLCOM_UPDATE: /* fall through */
|
|
|
|
case SQLCOM_UPDATE_MULTI:
|
|
|
|
new_trg_event_map|= static_cast<uint8>
|
|
|
|
(1 << static_cast<int>(TRG_EVENT_UPDATE));
|
|
|
|
break;
|
|
|
|
/* Basic delete and multi-delete */
|
|
|
|
case SQLCOM_DELETE: /* fall through */
|
|
|
|
case SQLCOM_DELETE_MULTI:
|
|
|
|
new_trg_event_map|= static_cast<uint8>
|
|
|
|
(1 << static_cast<int>(TRG_EVENT_DELETE));
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (duplicates) {
|
|
|
|
case DUP_UPDATE:
|
|
|
|
new_trg_event_map|= static_cast<uint8>
|
|
|
|
(1 << static_cast<int>(TRG_EVENT_UPDATE));
|
|
|
|
break;
|
|
|
|
case DUP_REPLACE:
|
|
|
|
new_trg_event_map|= static_cast<uint8>
|
|
|
|
(1 << static_cast<int>(TRG_EVENT_DELETE));
|
|
|
|
break;
|
|
|
|
case DUP_ERROR:
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
A fix and a test case for Bug#26141 mixing table types in trigger
causes full table lock on innodb table.
Also fixes Bug#28502 Triggers that update another innodb table
will block on X lock unnecessarily (duplciate).
Code review fixes.
Both bugs' synopses are misleading: InnoDB table is
not X locked. The statements, however, cannot proceed concurrently,
but this happens due to lock conflicts for tables used in triggers,
not for the InnoDB table.
If a user had an InnoDB table, and two triggers, AFTER UPDATE and
AFTER INSERT, competing for different resources (e.g. two distinct
MyISAM tables), then these two triggers would not be able to execute
concurrently. Moreover, INSERTS/UPDATES of the InnoDB table would
not be able to run concurrently.
The problem had other side-effects (see respective bug reports).
This behavior was a consequence of a shortcoming of the pre-locking
algorithm, which would not distinguish between different DML operations
(e.g. INSERT and DELETE) and pre-lock all the tables
that are used by any trigger defined on the subject table.
The idea of the fix is to extend the pre-locking algorithm to keep track,
for each table, what DML operation it is used for and not
load triggers that are known to never be fired.
2007-07-12 20:26:41 +02:00
|
|
|
/*
|
|
|
|
Do not iterate over sub-selects, only the tables in the outermost
|
|
|
|
SELECT_LEX can be modified, if any.
|
|
|
|
*/
|
|
|
|
TABLE_LIST *tables= select_lex.get_table_list();
|
|
|
|
|
|
|
|
while (tables)
|
|
|
|
{
|
2007-07-27 16:56:29 +02:00
|
|
|
/*
|
|
|
|
This is a fast check to filter out statements that do
|
|
|
|
not change data, or tables on the right side, in case of
|
|
|
|
INSERT .. SELECT, CREATE TABLE .. SELECT and so on.
|
|
|
|
Here we also filter out OPTIMIZE statement and non-updateable
|
|
|
|
views, for which lock_type is TL_UNLOCK or TL_READ after
|
|
|
|
parsing.
|
|
|
|
*/
|
|
|
|
if (static_cast<int>(tables->lock_type) >=
|
|
|
|
static_cast<int>(TL_WRITE_ALLOW_WRITE))
|
|
|
|
tables->trg_event_map= new_trg_event_map;
|
A fix and a test case for Bug#26141 mixing table types in trigger
causes full table lock on innodb table.
Also fixes Bug#28502 Triggers that update another innodb table
will block on X lock unnecessarily (duplciate).
Code review fixes.
Both bugs' synopses are misleading: InnoDB table is
not X locked. The statements, however, cannot proceed concurrently,
but this happens due to lock conflicts for tables used in triggers,
not for the InnoDB table.
If a user had an InnoDB table, and two triggers, AFTER UPDATE and
AFTER INSERT, competing for different resources (e.g. two distinct
MyISAM tables), then these two triggers would not be able to execute
concurrently. Moreover, INSERTS/UPDATES of the InnoDB table would
not be able to run concurrently.
The problem had other side-effects (see respective bug reports).
This behavior was a consequence of a shortcoming of the pre-locking
algorithm, which would not distinguish between different DML operations
(e.g. INSERT and DELETE) and pre-lock all the tables
that are used by any trigger defined on the subject table.
The idea of the fix is to extend the pre-locking algorithm to keep track,
for each table, what DML operation it is used for and not
load triggers that are known to never be fired.
2007-07-12 20:26:41 +02:00
|
|
|
tables= tables->next_local;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2004-04-07 23:16:17 +02:00
|
|
|
/*
|
2004-10-07 00:45:06 +02:00
|
|
|
Unlink the first table from the global table list and the first table from
|
|
|
|
outer select (lex->select_lex) local list
|
2004-04-07 23:16:17 +02:00
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
unlink_first_table()
|
2004-10-07 00:45:06 +02:00
|
|
|
link_to_local Set to 1 if caller should link this table to local list
|
2004-04-12 02:26:32 +02:00
|
|
|
|
2004-07-16 00:15:55 +02:00
|
|
|
NOTES
|
2004-10-07 00:45:06 +02:00
|
|
|
We assume that first tables in both lists is the same table or the local
|
|
|
|
list is empty.
|
2004-04-07 23:16:17 +02:00
|
|
|
|
|
|
|
RETURN
|
2004-09-03 20:43:04 +02:00
|
|
|
0 If 'query_tables' == 0
|
2004-07-16 00:15:55 +02:00
|
|
|
unlinked table
|
2004-09-03 20:43:04 +02:00
|
|
|
In this case link_to_local is set.
|
2004-04-12 02:26:32 +02:00
|
|
|
|
2004-04-07 23:16:17 +02:00
|
|
|
*/
|
2009-10-14 13:14:58 +02:00
|
|
|
TABLE_LIST *LEX::unlink_first_table(bool *link_to_local)
|
2004-04-07 23:16:17 +02:00
|
|
|
{
|
2004-07-16 00:15:55 +02:00
|
|
|
TABLE_LIST *first;
|
|
|
|
if ((first= query_tables))
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
Exclude from global table list
|
|
|
|
*/
|
|
|
|
if ((query_tables= query_tables->next_global))
|
|
|
|
query_tables->prev_global= &query_tables;
|
2005-03-04 14:35:28 +01:00
|
|
|
else
|
|
|
|
query_tables_last= &query_tables;
|
2004-07-16 00:15:55 +02:00
|
|
|
first->next_global= 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
and from local list if it is not empty
|
|
|
|
*/
|
|
|
|
if ((*link_to_local= test(select_lex.table_list.first)))
|
|
|
|
{
|
2005-08-18 02:12:42 +02:00
|
|
|
select_lex.context.table_list=
|
|
|
|
select_lex.context.first_name_resolution_table= first->next_local;
|
WL#3817: Simplify string / memory area types and make things more consistent (first part)
The following type conversions was done:
- Changed byte to uchar
- Changed gptr to uchar*
- Change my_string to char *
- Change my_size_t to size_t
- Change size_s to size_t
Removed declaration of byte, gptr, my_string, my_size_t and size_s.
Following function parameter changes was done:
- All string functions in mysys/strings was changed to use size_t
instead of uint for string lengths.
- All read()/write() functions changed to use size_t (including vio).
- All protocoll functions changed to use size_t instead of uint
- Functions that used a pointer to a string length was changed to use size_t*
- Changed malloc(), free() and related functions from using gptr to use void *
as this requires fewer casts in the code and is more in line with how the
standard functions work.
- Added extra length argument to dirname_part() to return the length of the
created string.
- Changed (at least) following functions to take uchar* as argument:
- db_dump()
- my_net_write()
- net_write_command()
- net_store_data()
- DBUG_DUMP()
- decimal2bin() & bin2decimal()
- Changed my_compress() and my_uncompress() to use size_t. Changed one
argument to my_uncompress() from a pointer to a value as we only return
one value (makes function easier to use).
- Changed type of 'pack_data' argument to packfrm() to avoid casts.
- Changed in readfrm() and writefrom(), ha_discover and handler::discover()
the type for argument 'frmdata' to uchar** to avoid casts.
- Changed most Field functions to use uchar* instead of char* (reduced a lot of
casts).
- Changed field->val_xxx(xxx, new_ptr) to take const pointers.
Other changes:
- Removed a lot of not needed casts
- Added a few new cast required by other changes
- Added some cast to my_multi_malloc() arguments for safety (as string lengths
needs to be uint, not size_t).
- Fixed all calls to hash-get-key functions to use size_t*. (Needed to be done
explicitely as this conflict was often hided by casting the function to
hash_get_key).
- Changed some buffers to memory regions to uchar* to avoid casts.
- Changed some string lengths from uint to size_t.
- Changed field->ptr to be uchar* instead of char*. This allowed us to
get rid of a lot of casts.
- Some changes from true -> TRUE, false -> FALSE, unsigned char -> uchar
- Include zlib.h in some files as we needed declaration of crc32()
- Changed MY_FILE_ERROR to be (size_t) -1.
- Changed many variables to hold the result of my_read() / my_write() to be
size_t. This was needed to properly detect errors (which are
returned as (size_t) -1).
- Removed some very old VMS code
- Changed packfrm()/unpackfrm() to not be depending on uint size
(portability fix)
- Removed windows specific code to restore cursor position as this
causes slowdown on windows and we should not mix read() and pread()
calls anyway as this is not thread safe. Updated function comment to
reflect this. Changed function that depended on original behavior of
my_pwrite() to itself restore the cursor position (one such case).
- Added some missing checking of return value of malloc().
- Changed definition of MOD_PAD_CHAR_TO_FULL_LENGTH to avoid 'long' overflow.
- Changed type of table_def::m_size from my_size_t to ulong to reflect that
m_size is the number of elements in the array, not a string/memory
length.
- Moved THD::max_row_length() to table.cc (as it's not depending on THD).
Inlined max_row_length_blob() into this function.
- More function comments
- Fixed some compiler warnings when compiled without partitions.
- Removed setting of LEX_STRING() arguments in declaration (portability fix).
- Some trivial indentation/variable name changes.
- Some trivial code simplifications:
- Replaced some calls to alloc_root + memcpy to use
strmake_root()/strdup_root().
- Changed some calls from memdup() to strmake() (Safety fix)
- Simpler loops in client-simple.c
2007-05-10 11:59:39 +02:00
|
|
|
select_lex.table_list.first= (uchar*) (first->next_local);
|
2004-07-16 00:15:55 +02:00
|
|
|
select_lex.table_list.elements--; //safety
|
|
|
|
first->next_local= 0;
|
|
|
|
/*
|
2004-10-07 00:45:06 +02:00
|
|
|
Ensure that the global list has the same first table as the local
|
|
|
|
list.
|
2004-07-16 00:15:55 +02:00
|
|
|
*/
|
|
|
|
first_lists_tables_same();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return first;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
Bring first local table of first most outer select to first place in global
|
|
|
|
table list
|
|
|
|
|
|
|
|
SYNOPSYS
|
2009-10-14 13:14:58 +02:00
|
|
|
LEX::first_lists_tables_same()
|
2004-07-16 00:15:55 +02:00
|
|
|
|
|
|
|
NOTES
|
2004-10-07 00:45:06 +02:00
|
|
|
In many cases (for example, usual INSERT/DELETE/...) the first table of
|
|
|
|
main SELECT_LEX have special meaning => check that it is the first table
|
|
|
|
in global list and re-link to be first in the global list if it is
|
|
|
|
necessary. We need such re-linking only for queries with sub-queries in
|
|
|
|
the select list, as only in this case tables of sub-queries will go to
|
|
|
|
the global list first.
|
2004-07-16 00:15:55 +02:00
|
|
|
*/
|
|
|
|
|
2009-10-14 13:14:58 +02:00
|
|
|
void LEX::first_lists_tables_same()
|
2004-07-16 00:15:55 +02:00
|
|
|
{
|
|
|
|
TABLE_LIST *first_table= (TABLE_LIST*) select_lex.table_list.first;
|
|
|
|
if (query_tables != first_table && first_table != 0)
|
|
|
|
{
|
2004-09-03 20:43:04 +02:00
|
|
|
TABLE_LIST *next;
|
2004-07-16 00:15:55 +02:00
|
|
|
if (query_tables_last == &first_table->next_global)
|
|
|
|
query_tables_last= first_table->prev_global;
|
2004-10-07 00:45:06 +02:00
|
|
|
|
2004-09-03 20:43:04 +02:00
|
|
|
if ((next= *first_table->prev_global= first_table->next_global))
|
2004-07-16 00:15:55 +02:00
|
|
|
next->prev_global= first_table->prev_global;
|
|
|
|
/* include in new place */
|
|
|
|
first_table->next_global= query_tables;
|
|
|
|
/*
|
2004-10-07 00:45:06 +02:00
|
|
|
We are sure that query_tables is not 0, because first_table was not
|
|
|
|
first table in the global list => we can use
|
|
|
|
query_tables->prev_global without check of query_tables
|
2004-07-16 00:15:55 +02:00
|
|
|
*/
|
|
|
|
query_tables->prev_global= &first_table->next_global;
|
|
|
|
first_table->prev_global= &query_tables;
|
|
|
|
query_tables= first_table;
|
|
|
|
}
|
2004-04-07 23:16:17 +02:00
|
|
|
}
|
|
|
|
|
2004-04-10 00:14:32 +02:00
|
|
|
|
2004-04-07 23:16:17 +02:00
|
|
|
/*
|
2004-04-10 00:14:32 +02:00
|
|
|
Link table back that was unlinked with unlink_first_table()
|
2004-04-07 23:16:17 +02:00
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
link_first_table_back()
|
2004-07-16 00:15:55 +02:00
|
|
|
link_to_local do we need link this table to local
|
2004-04-07 23:16:17 +02:00
|
|
|
|
|
|
|
RETURN
|
|
|
|
global list
|
|
|
|
*/
|
2004-07-16 00:15:55 +02:00
|
|
|
|
2009-10-14 13:14:58 +02:00
|
|
|
void LEX::link_first_table_back(TABLE_LIST *first,
|
2004-07-16 00:15:55 +02:00
|
|
|
bool link_to_local)
|
2004-04-07 23:16:17 +02:00
|
|
|
{
|
2004-07-16 00:15:55 +02:00
|
|
|
if (first)
|
2004-04-07 23:16:17 +02:00
|
|
|
{
|
2004-07-16 00:15:55 +02:00
|
|
|
if ((first->next_global= query_tables))
|
|
|
|
query_tables->prev_global= &first->next_global;
|
2005-03-04 14:35:28 +01:00
|
|
|
else
|
|
|
|
query_tables_last= &first->next_global;
|
2004-07-16 00:15:55 +02:00
|
|
|
query_tables= first;
|
|
|
|
|
|
|
|
if (link_to_local)
|
|
|
|
{
|
|
|
|
first->next_local= (TABLE_LIST*) select_lex.table_list.first;
|
2005-08-12 16:57:19 +02:00
|
|
|
select_lex.context.table_list= first;
|
WL#3817: Simplify string / memory area types and make things more consistent (first part)
The following type conversions was done:
- Changed byte to uchar
- Changed gptr to uchar*
- Change my_string to char *
- Change my_size_t to size_t
- Change size_s to size_t
Removed declaration of byte, gptr, my_string, my_size_t and size_s.
Following function parameter changes was done:
- All string functions in mysys/strings was changed to use size_t
instead of uint for string lengths.
- All read()/write() functions changed to use size_t (including vio).
- All protocoll functions changed to use size_t instead of uint
- Functions that used a pointer to a string length was changed to use size_t*
- Changed malloc(), free() and related functions from using gptr to use void *
as this requires fewer casts in the code and is more in line with how the
standard functions work.
- Added extra length argument to dirname_part() to return the length of the
created string.
- Changed (at least) following functions to take uchar* as argument:
- db_dump()
- my_net_write()
- net_write_command()
- net_store_data()
- DBUG_DUMP()
- decimal2bin() & bin2decimal()
- Changed my_compress() and my_uncompress() to use size_t. Changed one
argument to my_uncompress() from a pointer to a value as we only return
one value (makes function easier to use).
- Changed type of 'pack_data' argument to packfrm() to avoid casts.
- Changed in readfrm() and writefrom(), ha_discover and handler::discover()
the type for argument 'frmdata' to uchar** to avoid casts.
- Changed most Field functions to use uchar* instead of char* (reduced a lot of
casts).
- Changed field->val_xxx(xxx, new_ptr) to take const pointers.
Other changes:
- Removed a lot of not needed casts
- Added a few new cast required by other changes
- Added some cast to my_multi_malloc() arguments for safety (as string lengths
needs to be uint, not size_t).
- Fixed all calls to hash-get-key functions to use size_t*. (Needed to be done
explicitely as this conflict was often hided by casting the function to
hash_get_key).
- Changed some buffers to memory regions to uchar* to avoid casts.
- Changed some string lengths from uint to size_t.
- Changed field->ptr to be uchar* instead of char*. This allowed us to
get rid of a lot of casts.
- Some changes from true -> TRUE, false -> FALSE, unsigned char -> uchar
- Include zlib.h in some files as we needed declaration of crc32()
- Changed MY_FILE_ERROR to be (size_t) -1.
- Changed many variables to hold the result of my_read() / my_write() to be
size_t. This was needed to properly detect errors (which are
returned as (size_t) -1).
- Removed some very old VMS code
- Changed packfrm()/unpackfrm() to not be depending on uint size
(portability fix)
- Removed windows specific code to restore cursor position as this
causes slowdown on windows and we should not mix read() and pread()
calls anyway as this is not thread safe. Updated function comment to
reflect this. Changed function that depended on original behavior of
my_pwrite() to itself restore the cursor position (one such case).
- Added some missing checking of return value of malloc().
- Changed definition of MOD_PAD_CHAR_TO_FULL_LENGTH to avoid 'long' overflow.
- Changed type of table_def::m_size from my_size_t to ulong to reflect that
m_size is the number of elements in the array, not a string/memory
length.
- Moved THD::max_row_length() to table.cc (as it's not depending on THD).
Inlined max_row_length_blob() into this function.
- More function comments
- Fixed some compiler warnings when compiled without partitions.
- Removed setting of LEX_STRING() arguments in declaration (portability fix).
- Some trivial indentation/variable name changes.
- Some trivial code simplifications:
- Replaced some calls to alloc_root + memcpy to use
strmake_root()/strdup_root().
- Changed some calls from memdup() to strmake() (Safety fix)
- Simpler loops in client-simple.c
2007-05-10 11:59:39 +02:00
|
|
|
select_lex.table_list.first= (uchar*) first;
|
2004-07-16 00:15:55 +02:00
|
|
|
select_lex.table_list.elements++; //safety
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2005-07-05 12:37:02 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
cleanup lex for case when we open table by table for processing
|
|
|
|
|
|
|
|
SYNOPSIS
|
2009-10-14 13:14:58 +02:00
|
|
|
LEX::cleanup_after_one_table_open()
|
2006-05-30 07:45:23 +02:00
|
|
|
|
|
|
|
NOTE
|
|
|
|
This method is mostly responsible for cleaning up of selects lists and
|
|
|
|
derived tables state. To rollback changes in Query_tables_list one has
|
|
|
|
to call Query_tables_list::reset_query_tables_list(FALSE).
|
2005-07-05 12:37:02 +02:00
|
|
|
*/
|
|
|
|
|
2009-10-14 13:14:58 +02:00
|
|
|
void LEX::cleanup_after_one_table_open()
|
2005-07-05 12:37:02 +02:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
thd->lex->derived_tables & additional units may be set if we open
|
|
|
|
a view. It is necessary to clear thd->lex->derived_tables flag
|
|
|
|
to prevent processing of derived tables during next open_and_lock_tables
|
|
|
|
if next table is a real table and cleanup & remove underlying units
|
|
|
|
NOTE: all units will be connected to thd->lex->select_lex, because we
|
|
|
|
have not UNION on most upper level.
|
|
|
|
*/
|
|
|
|
if (all_selects_list != &select_lex)
|
|
|
|
{
|
|
|
|
derived_tables= 0;
|
|
|
|
/* cleunup underlying units (units of VIEW) */
|
|
|
|
for (SELECT_LEX_UNIT *un= select_lex.first_inner_unit();
|
|
|
|
un;
|
|
|
|
un= un->next_unit())
|
|
|
|
un->cleanup();
|
|
|
|
/* reduce all selects list to default state */
|
|
|
|
all_selects_list= &select_lex;
|
|
|
|
/* remove underlying units (units of VIEW) subtree */
|
|
|
|
select_lex.cut_subtree();
|
|
|
|
}
|
2006-05-30 07:45:23 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
Save current state of Query_tables_list for this LEX, and prepare it
|
|
|
|
for processing of new statemnt.
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
reset_n_backup_query_tables_list()
|
|
|
|
backup Pointer to Query_tables_list instance to be used for backup
|
|
|
|
*/
|
|
|
|
|
2009-10-14 13:14:58 +02:00
|
|
|
void LEX::reset_n_backup_query_tables_list(Query_tables_list *backup)
|
2006-05-30 07:45:23 +02:00
|
|
|
{
|
|
|
|
backup->set_query_tables_list(this);
|
|
|
|
/*
|
|
|
|
We have to perform full initialization here since otherwise we
|
|
|
|
will damage backed up state.
|
|
|
|
*/
|
|
|
|
this->reset_query_tables_list(TRUE);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
Restore state of Query_tables_list for this LEX from backup.
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
restore_backup_query_tables_list()
|
|
|
|
backup Pointer to Query_tables_list instance used for backup
|
|
|
|
*/
|
|
|
|
|
2009-10-14 13:14:58 +02:00
|
|
|
void LEX::restore_backup_query_tables_list(Query_tables_list *backup)
|
2006-05-30 07:45:23 +02:00
|
|
|
{
|
|
|
|
this->destroy_query_tables_list();
|
|
|
|
this->set_query_tables_list(backup);
|
2005-07-05 12:37:02 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2006-11-02 13:51:43 +01:00
|
|
|
/*
|
|
|
|
Checks for usage of routines and/or tables in a parsed statement
|
|
|
|
|
|
|
|
SYNOPSIS
|
2009-10-14 13:14:58 +02:00
|
|
|
LEX:table_or_sp_used()
|
2006-11-02 13:51:43 +01:00
|
|
|
|
|
|
|
RETURN
|
|
|
|
FALSE No routines and tables used
|
|
|
|
TRUE Either or both routines and tables are used.
|
|
|
|
*/
|
|
|
|
|
2009-10-14 13:14:58 +02:00
|
|
|
bool LEX::table_or_sp_used()
|
2006-11-02 13:51:43 +01:00
|
|
|
{
|
|
|
|
DBUG_ENTER("table_or_sp_used");
|
|
|
|
|
|
|
|
if (sroutines.records || query_tables)
|
|
|
|
DBUG_RETURN(TRUE);
|
|
|
|
|
|
|
|
DBUG_RETURN(FALSE);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2005-11-02 05:05:19 +01:00
|
|
|
/*
|
|
|
|
Do end-of-prepare fixup for list of tables and their merge-VIEWed tables
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
fix_prepare_info_in_table_list()
|
|
|
|
thd Thread handle
|
|
|
|
tbl List of tables to process
|
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
Perform end-end-of prepare fixup for list of tables, if any of the tables
|
|
|
|
is a merge-algorithm VIEW, recursively fix up its underlying tables as
|
|
|
|
well.
|
|
|
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
static void fix_prepare_info_in_table_list(THD *thd, TABLE_LIST *tbl)
|
|
|
|
{
|
|
|
|
for (; tbl; tbl= tbl->next_local)
|
|
|
|
{
|
|
|
|
if (tbl->on_expr)
|
|
|
|
{
|
|
|
|
tbl->prep_on_expr= tbl->on_expr;
|
|
|
|
tbl->on_expr= tbl->on_expr->copy_andor_structure(thd);
|
|
|
|
}
|
|
|
|
fix_prepare_info_in_table_list(thd, tbl->merge_underlying_list);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2004-07-16 00:15:55 +02:00
|
|
|
/*
|
2006-09-16 18:50:48 +02:00
|
|
|
Save WHERE/HAVING/ON clauses and replace them with disposable copies
|
2004-07-16 00:15:55 +02:00
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
st_select_lex::fix_prepare_information
|
2006-09-16 18:50:48 +02:00
|
|
|
thd thread handler
|
|
|
|
conds in/out pointer to WHERE condition to be met at execution
|
|
|
|
having_conds in/out pointer to HAVING condition to be met at execution
|
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
The passed WHERE and HAVING are to be saved for the future executions.
|
|
|
|
This function saves it, and returns a copy which can be thrashed during
|
|
|
|
this execution of the statement. By saving/thrashing here we mean only
|
|
|
|
AND/OR trees.
|
|
|
|
The function also calls fix_prepare_info_in_table_list that saves all
|
|
|
|
ON expressions.
|
2004-07-16 00:15:55 +02:00
|
|
|
*/
|
|
|
|
|
2006-09-16 18:50:48 +02:00
|
|
|
void st_select_lex::fix_prepare_information(THD *thd, Item **conds,
|
|
|
|
Item **having_conds)
|
2004-07-16 00:15:55 +02:00
|
|
|
{
|
2005-09-02 15:21:19 +02:00
|
|
|
if (!thd->stmt_arena->is_conventional() && first_execution)
|
2004-07-16 00:15:55 +02:00
|
|
|
{
|
|
|
|
first_execution= 0;
|
2005-07-01 06:05:42 +02:00
|
|
|
if (*conds)
|
|
|
|
{
|
|
|
|
prep_where= *conds;
|
|
|
|
*conds= where= prep_where->copy_andor_structure(thd);
|
|
|
|
}
|
2006-09-16 18:50:48 +02:00
|
|
|
if (*having_conds)
|
|
|
|
{
|
|
|
|
prep_having= *having_conds;
|
|
|
|
*having_conds= having= prep_having->copy_andor_structure(thd);
|
|
|
|
}
|
2005-11-02 05:05:19 +01:00
|
|
|
fix_prepare_info_in_table_list(thd, (TABLE_LIST *)table_list.first);
|
2004-04-07 23:16:17 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-11-02 13:51:43 +01:00
|
|
|
|
2002-11-23 17:54:15 +01:00
|
|
|
/*
|
2004-07-16 00:15:55 +02:00
|
|
|
There are st_select_lex::add_table_to_list &
|
2004-02-08 19:14:13 +01:00
|
|
|
st_select_lex::set_lock_for_tables are in sql_parse.cc
|
2003-10-16 14:54:47 +02:00
|
|
|
|
2004-07-16 00:15:55 +02:00
|
|
|
st_select_lex::print is in sql_select.cc
|
2004-02-08 19:14:13 +01:00
|
|
|
|
|
|
|
st_select_lex_unit::prepare, st_select_lex_unit::exec,
|
2004-05-07 22:06:11 +02:00
|
|
|
st_select_lex_unit::cleanup, st_select_lex_unit::reinit_exec_mechanism,
|
|
|
|
st_select_lex_unit::change_result
|
2004-02-08 19:14:13 +01:00
|
|
|
are in sql_union.cc
|
2002-11-23 17:54:15 +01:00
|
|
|
*/
|
2005-07-01 06:05:42 +02:00
|
|
|
|
2007-03-05 18:08:41 +01:00
|
|
|
/*
|
|
|
|
Sets the kind of hints to be added by the calls to add_index_hint().
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
set_index_hint_type()
|
2007-08-13 15:11:25 +02:00
|
|
|
type_arg The kind of hints to be added from now on.
|
|
|
|
clause The clause to use for hints to be added from now on.
|
2007-03-05 18:08:41 +01:00
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
Used in filling up the tagged hints list.
|
|
|
|
This list is filled by first setting the kind of the hint as a
|
|
|
|
context variable and then adding hints of the current kind.
|
|
|
|
Then the context variable index_hint_type can be reset to the
|
|
|
|
next hint type.
|
|
|
|
*/
|
2007-08-13 15:11:25 +02:00
|
|
|
void st_select_lex::set_index_hint_type(enum index_hint_type type_arg,
|
2007-03-05 18:08:41 +01:00
|
|
|
index_clause_map clause)
|
|
|
|
{
|
2007-08-13 15:11:25 +02:00
|
|
|
current_index_hint_type= type_arg;
|
2007-03-05 18:08:41 +01:00
|
|
|
current_index_hint_clause= clause;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
Makes an array to store index usage hints (ADD/FORCE/IGNORE INDEX).
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
alloc_index_hints()
|
|
|
|
thd current thread.
|
|
|
|
*/
|
|
|
|
|
|
|
|
void st_select_lex::alloc_index_hints (THD *thd)
|
|
|
|
{
|
2007-07-23 18:09:48 +02:00
|
|
|
index_hints= new (thd->mem_root) List<Index_hint>();
|
2007-03-05 18:08:41 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
adds an element to the array storing index usage hints
|
|
|
|
(ADD/FORCE/IGNORE INDEX).
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
add_index_hint()
|
|
|
|
thd current thread.
|
|
|
|
str name of the index.
|
|
|
|
length number of characters in str.
|
|
|
|
|
|
|
|
RETURN VALUE
|
|
|
|
0 on success, non-zero otherwise
|
|
|
|
*/
|
|
|
|
bool st_select_lex::add_index_hint (THD *thd, char *str, uint length)
|
|
|
|
{
|
|
|
|
return index_hints->push_front (new (thd->mem_root)
|
2007-07-23 18:09:48 +02:00
|
|
|
Index_hint(current_index_hint_type,
|
2007-03-05 18:08:41 +01:00
|
|
|
current_index_hint_clause,
|
|
|
|
str, length));
|
|
|
|
}
|
5.1 version of a fix and test cases for bugs:
Bug#4968 ""Stored procedure crash if cursor opened on altered table"
Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing"
Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from
stored procedure."
Bug#19733 "Repeated alter, or repeated create/drop, fails"
Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server"
Bug#24879 "Prepared Statements: CREATE TABLE (UTF8 KEY) produces a
growing key length" (this bug is not fixed in 5.0)
Re-execution of CREATE DATABASE, CREATE TABLE and ALTER TABLE
statements in stored routines or as prepared statements caused
incorrect results (and crashes in versions prior to 5.0.25).
In 5.1 the problem occured only for CREATE DATABASE, CREATE TABLE
SELECT and CREATE TABLE with INDEX/DATA DIRECTOY options).
The problem of bugs 4968, 19733, 19282 and 6895 was that functions
mysql_prepare_table, mysql_create_table and mysql_alter_table are not
re-execution friendly: during their operation they modify contents
of LEX (members create_info, alter_info, key_list, create_list),
thus making the LEX unusable for the next execution.
In particular, these functions removed processed columns and keys from
create_list, key_list and drop_list. Search the code in sql_table.cc
for drop_it.remove() and similar patterns to find evidence.
The fix is to supply to these functions a usable copy of each of the
above structures at every re-execution of an SQL statement.
To simplify memory management, LEX::key_list and LEX::create_list
were added to LEX::alter_info, a fresh copy of which is created for
every execution.
The problem of crashing bug 22060 stemmed from the fact that the above
metnioned functions were not only modifying HA_CREATE_INFO structure
in LEX, but also were changing it to point to areas in volatile memory
of the execution memory root.
The patch solves this problem by creating and using an on-stack
copy of HA_CREATE_INFO in mysql_execute_command.
Additionally, this patch splits the part of mysql_alter_table
that analizes and rewrites information from the parser into
a separate function - mysql_prepare_alter_table, in analogy with
mysql_prepare_table, which is renamed to mysql_prepare_create_table.
2007-05-28 13:30:01 +02:00
|
|
|
|
|
|
|
/**
|
|
|
|
A routine used by the parser to decide whether we are specifying a full
|
|
|
|
partitioning or if only partitions to add or to split.
|
|
|
|
|
|
|
|
@note This needs to be outside of WITH_PARTITION_STORAGE_ENGINE since it
|
2007-08-16 17:52:55 +02:00
|
|
|
is used from the sql parser that doesn't have any ifdef's
|
5.1 version of a fix and test cases for bugs:
Bug#4968 ""Stored procedure crash if cursor opened on altered table"
Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing"
Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from
stored procedure."
Bug#19733 "Repeated alter, or repeated create/drop, fails"
Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server"
Bug#24879 "Prepared Statements: CREATE TABLE (UTF8 KEY) produces a
growing key length" (this bug is not fixed in 5.0)
Re-execution of CREATE DATABASE, CREATE TABLE and ALTER TABLE
statements in stored routines or as prepared statements caused
incorrect results (and crashes in versions prior to 5.0.25).
In 5.1 the problem occured only for CREATE DATABASE, CREATE TABLE
SELECT and CREATE TABLE with INDEX/DATA DIRECTOY options).
The problem of bugs 4968, 19733, 19282 and 6895 was that functions
mysql_prepare_table, mysql_create_table and mysql_alter_table are not
re-execution friendly: during their operation they modify contents
of LEX (members create_info, alter_info, key_list, create_list),
thus making the LEX unusable for the next execution.
In particular, these functions removed processed columns and keys from
create_list, key_list and drop_list. Search the code in sql_table.cc
for drop_it.remove() and similar patterns to find evidence.
The fix is to supply to these functions a usable copy of each of the
above structures at every re-execution of an SQL statement.
To simplify memory management, LEX::key_list and LEX::create_list
were added to LEX::alter_info, a fresh copy of which is created for
every execution.
The problem of crashing bug 22060 stemmed from the fact that the above
metnioned functions were not only modifying HA_CREATE_INFO structure
in LEX, but also were changing it to point to areas in volatile memory
of the execution memory root.
The patch solves this problem by creating and using an on-stack
copy of HA_CREATE_INFO in mysql_execute_command.
Additionally, this patch splits the part of mysql_alter_table
that analizes and rewrites information from the parser into
a separate function - mysql_prepare_alter_table, in analogy with
mysql_prepare_table, which is renamed to mysql_prepare_create_table.
2007-05-28 13:30:01 +02:00
|
|
|
|
|
|
|
@retval TRUE Yes, it is part of a management partition command
|
|
|
|
@retval FALSE No, not a management partition command
|
|
|
|
*/
|
|
|
|
|
2009-10-14 13:14:58 +02:00
|
|
|
bool LEX::is_partition_management() const
|
5.1 version of a fix and test cases for bugs:
Bug#4968 ""Stored procedure crash if cursor opened on altered table"
Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing"
Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from
stored procedure."
Bug#19733 "Repeated alter, or repeated create/drop, fails"
Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server"
Bug#24879 "Prepared Statements: CREATE TABLE (UTF8 KEY) produces a
growing key length" (this bug is not fixed in 5.0)
Re-execution of CREATE DATABASE, CREATE TABLE and ALTER TABLE
statements in stored routines or as prepared statements caused
incorrect results (and crashes in versions prior to 5.0.25).
In 5.1 the problem occured only for CREATE DATABASE, CREATE TABLE
SELECT and CREATE TABLE with INDEX/DATA DIRECTOY options).
The problem of bugs 4968, 19733, 19282 and 6895 was that functions
mysql_prepare_table, mysql_create_table and mysql_alter_table are not
re-execution friendly: during their operation they modify contents
of LEX (members create_info, alter_info, key_list, create_list),
thus making the LEX unusable for the next execution.
In particular, these functions removed processed columns and keys from
create_list, key_list and drop_list. Search the code in sql_table.cc
for drop_it.remove() and similar patterns to find evidence.
The fix is to supply to these functions a usable copy of each of the
above structures at every re-execution of an SQL statement.
To simplify memory management, LEX::key_list and LEX::create_list
were added to LEX::alter_info, a fresh copy of which is created for
every execution.
The problem of crashing bug 22060 stemmed from the fact that the above
metnioned functions were not only modifying HA_CREATE_INFO structure
in LEX, but also were changing it to point to areas in volatile memory
of the execution memory root.
The patch solves this problem by creating and using an on-stack
copy of HA_CREATE_INFO in mysql_execute_command.
Additionally, this patch splits the part of mysql_alter_table
that analizes and rewrites information from the parser into
a separate function - mysql_prepare_alter_table, in analogy with
mysql_prepare_table, which is renamed to mysql_prepare_create_table.
2007-05-28 13:30:01 +02:00
|
|
|
{
|
|
|
|
return (sql_command == SQLCOM_ALTER_TABLE &&
|
|
|
|
(alter_info.flags == ALTER_ADD_PARTITION ||
|
|
|
|
alter_info.flags == ALTER_REORGANIZE_PARTITION));
|
|
|
|
}
|
|
|
|
|