A fix and a test case for Bug#15441 "Running SP causes Server

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.


mysql-test/r/sp.result:
  Test results fixed (Bug#15441).
  Also make sure that the recently added test cases follow sp.test
  internal tests standard.
mysql-test/t/sp.test:
  Add a test case for Bug#15441 "Running SP causes Server to Crash".
sql/item.cc:
  Cleanup Item_insert_value::fix_fields().
sql/item.h:
  Add a comment for Item_insert_value.
sql/sql_yacc.yy:
  Actual fix for Bug#15441 "Running SP causes Server to Crash":
  we should not allow VALUES() function to reference SP variables.

1 files changed, 10 insertions, 0 deletions

diff --git a/sql/item.h b/sql/item.h
index 900442a45e9..9eb2e6dee88 100644
--- a/sql/item.h
+++ b/sql/item.h
@@ -2056,6 +2056,16 @@ public:
   }
 };
 
+/*
+  Item_insert_value -- an implementation of VALUES() function.
+  You can use the VALUES(col_name) function in the UPDATE clause
+  to refer to column values from the INSERT portion of the INSERT
+  ... UPDATE statement. In other words, VALUES(col_name) in the
+  UPDATE clause refers to the value of col_name that would be
+  inserted, had no duplicate-key conflict occurred.
+  In all other places this function returns NULL.
+*/
+
 class Item_insert_value : public Item_field
 {
 public: