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.
This commit is contained in:
unknown 2005-12-09 00:58:59 +03:00
commit 9c4985de77
5 changed files with 139 additions and 36 deletions

View file

@ -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: