Parser rejects ODBC's escape sequences for outer joins other
than left outer join, yet the escape sequence BNF specifies
that this syntax can be used for left, right, and full outer
join syntax.
The problem is that although the MySQL Connector/ODBC advertises
"Outer Join Escape Sequence" capabilities, the parsing is done
in the server and historically it only supported this syntax
for left outer joins and applications such as Crystal Reports
11 tries to use this syntax for inner joins.
The chosen solution is to reorganize a couple of parser rules
to ignore any kind of SQL escape sequence. Ignoring the escape
sequences is harmless because the various SQL join clauses
are supported by the server.
Parser rejects valid INTERVAL() expressions when associated with
arithmetic operators. The problem is the way in which the expression
and interval grammar rules were organized caused shift/reduce conflicts.
The solution is to tweak the interval rules to avoid shift/reduce
conflicts by removing the broken interval_expr rule and explicitly
specify it's content where necessary.
Original fix by Davi Arnaut, revised and improved rules by Marc Alff
ANSI_QUOTES mode)
This patch contains a test case only, showing that the bug has been fixed.
The issue was related to parsing <"blah">, where the lexical analyser
would not properly delimit the start and end of the token.
Properly making the token boundaries has been fixed in sql_lex.cc
with the patch for bug 25411 : see the Lex_input_stream class.
According to some internal communication, these two functions are place
holders for future enhancements. Because they use a variable number of
parameters, the implementation defined a reserved keyword for them in the
parser grammar.
Unfortunately, doing so creates a bug similar to Bug 21114 reported for the
function FORMAT.
In the 5.1 code base, due to improvements in the code implemented with bug
21114, having a reserved keyword for functions with a variable number of
arguments is not needed any more by the implementation.
As a result, this fix removes the place-holder implementation, and removes
the unnecessary reserved keywords. Should the functions UNIQUE_USERS and
GROUP_UNIQUE_USERS be finally implemented in a later release, the
implementation should sub class Create_native_func in sql/item_create.cc.
For example, see the class Create_func_concat.
Before this fix, a call to a User Defined Function (UDF) could,
under some circumstances, be interpreted as a call to a Stored function
instead. This occurred if a native function was invoked in the parameters
for the UDF, as in "select my_udf(abs(x))".
The root cause of this defect is the introduction, by the fix for Bug 21809,
of st_select_lex::udf_list, and it's usage in the parser in sql_yacc.yy
in the rule function_call_generic (in 5.1).
While the fix itself for Bug 21809 is correct in 5.0, the code change
merged into the 5.1 release created the issue, because the calls in 5.1 to :
- lex->current_select->udf_list.push_front(udf)
- lex->current_select->udf_list.pop()
are not balanced in case of native functions, causing the udf_list,
which is really a stack, to be out of sync with the internal stack
maintained by the bison parser.
Instead of moving the call to udf_list.pop(), which would have fixed the
symptom, this patch goes further and removes the need for udf_list.
This is motivated by two reasons:
a) Maintaining a stack in the MySQL code in sync with the stack maintained
internally in sql_yacc.cc (not .yy) is extremely dependent of the
implementation of yacc/bison, and extremely difficult to maintain.
It's also totally dependent of the structure of the grammar, and has a risk
to break with regression defects each time the grammar itself is changed.
b) The previous code did report construct like "foo(expr AS name)" as
syntax errors (ER_PARSER_ERROR), which is incorrect, and misleading.
The syntax is perfectly valid, as this expression is valid when "foo" is
a UDF. Whether this syntax is legal or not depends of the semantic of "foo".
With this change:
a) There is only one stack (in bison), and no List<udf_func> to maintain.
b) "foo(expr AS name)", when used incorrectly, is reported as semantic error:
- ER_WRONG_PARAMETERS_TO_NATIVE_FCT (for native functions)
- ER_WRONG_PARAMETERS_TO_STORED_FCT (for stored functions)
This is achieved by the changes implemented in item_create.cc
Before this change, the functions BENCHMARK, ENCODE, DECODE and FORMAT could
only accept a constant for some parameters.
After this change, this restriction has been removed. An implication is that
these functions can also be used in prepared statements.
The change consist of changing the following classes:
- Item_func_benchmark
- Item_func_encode
- Item_func_decode
- Item_func_format
to:
- only accept Item* in the constructor,
- and evaluate arguments during calls to val_xxx()
which fits the general design of all the other functions.
The 'TODO' items identified in item_create.cc during the work done for
Bug 21114 are addressed by this fix, as a natural consequence of aligning
the design.
In the 'func_str' test, a single very long test line involving an explain
extended select with many functions has been rewritten into multiple
separate tests, to improve maintainability.
The result of explain extended select decode(encode(...)) has changed,
since the encode and decode functions now print all their parameters.
Due to the complexity of this change, everything is documented in WL#3565
This patch is the third iteration, it takes into account the comments
received to date.
