On 21.10.14 17:40, Sergei Golubchik wrote: [skip]
+SET STATEMENT sort_buffer_size=150000 FOR SELECT * FROM t2; +ERROR 42S02: Table 'test.t2' doesn't exist +'' +'# Post-STATEMENT variable value' +SHOW SESSION VARIABLES LIKE 'sort_buffer_size'; +Variable_name Value +sort_buffer_size 150000 Looks wrong. The value is not restored in case of an error. fixed. It was problem that sql_set_variables was not working correctly is you enter it with already happened error. But the test was good, I hope you kept it.
yes of course
create event e_53 on schedule every (select s1 from ttx) second do drop table t; -ERROR 42000: This version of MariaDB doesn't yet support 'Usage of subqueries or stored function calls as part of this statement' +ERROR HY000: CREATE/ALTER EVENT does not support subqueries or stored functions. create event e_53 on schedule every 5 second starts (select s1 from ttx) do drop table t; -ERROR 42000: This version of MariaDB doesn't yet support 'Usage of subqueries or stored function calls as part of this statement' +ERROR HY000: CREATE/ALTER EVENT does not support subqueries or stored functions. create event e_53 on schedule every 5 second ends (select s1 from ttx) do drop table t; -ERROR 42000: This version of MariaDB doesn't yet support 'Usage of subqueries or stored function calls as part of this statement' +ERROR HY000: CREATE/ALTER EVENT does not support subqueries or stored functions. drop event if exists e_16; drop procedure if exists p_16; create event e_16 on schedule every 1 second do set @a=5; diff --git a/mysql-test/t/set_statement.test b/mysql-test/t/set_statement.test index 3ea9235..9a2e577 100644 --- a/mysql-test/t/set_statement.test +++ b/mysql-test/t/set_statement.test @@ -661,10 +610,92 @@ SELECT @@sql_mode; --echo '' SET STATEMENT sql_mode='ansi' FOR PREPARE stmt FROM 'SELECT "t1".* FROM t1'; execute stmt; +ALTER TABLE t1 ADD COLUMN v3 int; +# repreparation with other mode cause an error +--error ER_PARSE_ERROR +execute stmt; +ALTER TABLE t1 drop COLUMN v3; deallocate prepare stmt; --echo '' --echo '# Post-STATEMENT SELECT @@sql_mode; +--echo check the same behaviour in normal set +SET sql_mode='ansi'; +PREPARE stmt FROM 'SELECT "t1".* FROM t1'; +SET sql_mode=default; +execute stmt; +ALTER TABLE t1 ADD COLUMN v3 int; +# repreparation with other mode cause an error +--error ER_PARSE_ERROR +execute stmt; +ALTER TABLE t1 drop COLUMN v3; +deallocate prepare stmt; +# the above test about SP +SELECT @@sql_mode; +SET sql_mode='ansi'; +SELECT @@sql_mode; +DELIMITER |; + CREATE PROCEDURE p6() BEGIN + SELECT @@sql_mode; + SELECT "t1".* FROM t1; + END| +DELIMITER ;| +SET sql_mode=default; +call p6; +ALTER TABLE t1 ADD COLUMN v3 int; +--echo # no reparsing for now You can still force re-parsing by somehow flushing the SP cache. E.g. you can start a new connection and run the SP there, try that, please.
I found that creating/dropping view flushes the cache and used it [skip]
if (v->var->is_default()) o= new set_var(v->type, v->var, &v->base, NULL); else @@ -2727,6 +2732,11 @@ static bool do_execute_sp(THD *thd, sp_head *sp) my_error(ER_WRONG_ARGUMENTS, MYF(0), "SET"); goto error; } + if (lex->sql_command == SQLCOM_COMPOUND) + { + /* mode might be changed by SET STATEMENT */ + lex->sphead->m_sql_mode= thd->variables.sql_mode; + } In fact, it might be that you don't need that and you can remove my fix for MDEV-6609 and simply put this assignment into 'case SQLCOM_COMPOUND:'
I did so and removed yours fix. [skip]