Bug#19356: Assert on undefined @uservar in prepared statement execute
The executing code had a safety assertion so that it refused to free Items that it didn't create. However, there is a case, undefined user variables, which would put Items into the list to be freed. Instead, do something that is more risky in expectation that the code will be refactored soon, as Kostja wants to do: Remove the assertions from prepare() and execute(). Put one assertion at a higher level, before stmt->set_params_from_vars(), which may then create new to-be-freed Items . mysql-test/r/ps_11bugs.result: Create tests to prove that undefined variables work, as keys and not, and that variables explicitly assigned to Null work. mysql-test/t/ps_11bugs.test: Create tests to prove that undefined variables work, as keys and not, and that variables explicitly assigned to Null work. sql/sql_prepare.cc: Move a safety assertion up one level and higher, because there is legitimately a case where thd->free_list is not NULL going into Prepared_statement::{prepare,execute} methods. Kostja plans to refactor this code so that it is both safe and works. (Now it works, but isn't very safe.)
Showing
Please register or sign in to comment