Absence of table in left part of LEFT/RIGHT join wasn't checked before
name resolution which resulted in NULL dereferencing and server crash.
Modified rules:
"table_ref LEFT opt_outer JOIN_SYM table_ref" and "table_ref RIGHT opt_outer
JOIN_SYM table_ref"
NULL check is moved before push_new_name_resolution_context()
to Crash": the bug was that due to non-standard name
resolution precedence in stored procedures (See Bug#5967)
a stored procedure variable took precedence over a table column
when the arguments for VALUES() function were resolved.
The implementation of VALUES() function was not designed to work
with Item_splocal and crashed.
VALUES() function is non-standard. It can refer to, and
is meaningful for, table columns only. The patch disables SP
variables as possible arguments of VALUES() function.
according to the standard.
The idea is to use Field-classes to implement stored routines
variables. Also, we should provide facade to Item-hierarchy
by Item_field class (it is necessary, since SRVs take part
in expressions).
The patch fixes the following bugs:
- BUG#8702: Stored Procedures: No Error/Warning shown for inappropriate data
type matching;
- BUG#8768: Functions: For any unsigned data type, -ve values can be passed
and returned;
- BUG#8769: Functions: For Int datatypes, out of range values can be passed
and returned;
- BUG#9078: STORED PROCDURE: Decimal digits are not displayed when we use
DECIMAL datatype;
- BUG#9572: Stored procedures: variable type declarations ignored;
- BUG#12903: upper function does not work inside a function;
- BUG#13705: parameters to stored procedures are not verified;
- BUG#13808: ENUM type stored procedure parameter accepts non-enumerated
data;
- BUG#13909: Varchar Stored Procedure Parameter always BINARY string (ignores
CHARACTER SET);
- BUG#14161: Stored procedure cannot retrieve bigint unsigned;
- BUG#14188: BINARY variables have no 0x00 padding;
- BUG#15148: Stored procedure variables accept non-scalar values;
of SELECT from query begining, to be independet of query buffer
allocation.
Correct procedure used to find beginning of the current statement
during parsing (BUG#14885).
Post-review version. Some minor review fixes, but also changed the way
some errors are handled: Don't return specific parse errors; instead
always use the more general "table corrupt" error (amended accordingly).
if inner routine has more local variables than outer one, and
one of its last variables was used as argument to NOT operator".
THD::spcont was non-0 when we were parsing stored routine/trigger
definition during execution of another stored routine. This confused
methods of Item_splocal and forced them use wrong runtime context.
Fix ensures that we always have THD::spcont equal to zero during
routine/trigger body parsing. This also allows to avoid problems
with errors which occur during parsing and SQL exception handlers.
Since long, the compiled code of stored routines has been printed in the trace file
when starting mysqld with the "--debug" flag. (At creation time only, and only in
debug builds of course.) This has been helpful when debugging stored procedure
execution, but it's a bit awkward to use. Also, the printing of some of the
instructions is a bit terse, in particular for sp_instr_stmt where only the command
code was printed.
This improves the printout of several of the instructions, and adds the debugging-
only commands "show procedure code <name>" and "show function code <name>".
(In non-debug builds they are not available.)
The crash mentioned in original bug report is already prevented by one
of previous patches (fix for bug #13343 "CREATE|etc TRIGGER|VIEW|USER
don't commit the transaction (inconsistency)"), this patch only improve
error returning.
Changed the parser test for wildcards in hostname to checking for empty
strings instead (analogous with the test in default_view_definer()),
since wildcards do appear in the definer's host-part sometimes.
The cause for the bug is that the priorities of all rules/terminals
that process the FROM clause are not fully specified, and the
parser generator produces a parser that doesn't always parse
the FROM clause so that JOINs are left-associative. As a result
the final join tree produced by the parser is incorrect, which
is the cause for subsequent name resolution to fail.
ESCAPE has length of 1 if specified and sql_mode is NO_BACKSLASH_ESCAPES
or has length of 0 or 1 in every other situation.
(approved patch applied on a up-to-date tree re-commit)
New syntax: CHAR(x USING charset)
Adding test case.
sql_yacc.yy:
New syntax: CHAR(x USING charset)
Adding new parser rule.
item_strfunc.h:
New syntax: CHAR(x USING charset)
Adding a new constructor.
