Commit 64c059b0 authored by Magne Mahre's avatar Magne Mahre

Bug#58199 name_const in the having clause crashes

      
NAME_CONST(..) was used wrongly in a HAVING clause, and
should have caused a user error.  Instead, it caused a
segmentation fault.
      
During parsing, the value parameter to NAME_CONST was
specified to be an uninitialized Item_ref object (it
would be resolved later).   During the semantic analysis,
the object is tested, and since it was not initialied,
the server seg.faulted.
      
The fix is to check if the object is initialized
before testing it.  The same pattern has already been
applied to most other methods in the Item_ref class.
      
Bug was introduced by the optimization done as part of
Bug#33546.
parent afcf7bc7
......@@ -375,4 +375,10 @@ GREATEST(a, (SELECT b FROM t1 LIMIT 1))
3
1
DROP TABLE t1;
End of 5.1 tests
#
# Bug #58199: name_const in the having clause crashes
#
CREATE TABLE t1 (a INT);
SELECT 1 from t1 HAVING NAME_CONST('', a);
ERROR HY000: Incorrect arguments to NAME_CONST
DROP TABLE t1;
......@@ -504,4 +504,15 @@ SELECT DISTINCT GREATEST(a, (SELECT b FROM t1 LIMIT 1)) FROM t1 UNION SELECT 1;
DROP TABLE t1;
--echo End of 5.1 tests
--echo #
--echo # Bug #58199: name_const in the having clause crashes
--echo #
CREATE TABLE t1 (a INT);
# NAME_CONST() would seg.fault when used wrongly in a HAVING clause
--error ER_WRONG_ARGUMENTS
SELECT 1 from t1 HAVING NAME_CONST('', a);
DROP TABLE t1;
......@@ -2572,7 +2572,7 @@ public:
DBUG_ASSERT(fixed);
return (*ref)->get_time(ltime);
}
virtual bool basic_const_item() const { return (*ref)->basic_const_item(); }
virtual bool basic_const_item() const { return ref && (*ref)->basic_const_item(); }
bool is_outer_field() const
{
DBUG_ASSERT(fixed);
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment