-
unknown authored
The idea is to use TABLE_LIST::lock_type for passing type of lock for target table to mysql_load() instead of using LEX::lock_option (which were rewritten by first subselect in SET clause). This should also fix potential problem with LOAD DATA in SP (it is important for them to have right lock_type in the table list by the end of statement parsing). mysql-test/r/loaddata.result: Added nice test for LOAD DATA with subquery. mysql-test/t/loaddata.test: Added nice test for LOAD DATA with subquery. sql/log_event.cc: Now we don't pass type of lock for target table to mysql_load() explicitly . Instead we use TABLE_LIST::lock_type for this table which is already properly set here. sql/mysql_priv.h: Now we don't pass type of lock for target table to mysql_load() explicitly . Instead we properly set TABLE_LIST::lock_type for this table in parser. sql/sql_load.cc: Now we don't pass type of lock for target table to mysql_load() explicitly . Instead we properly set TABLE_LIST::lock_type for this table in parser. sql/sql_parse.cc: Now we don't pass type of lock for target table to mysql_load() explicitly . Instead we properly set TABLE_LIST::lock_type for this table in parser. sql/sql_yacc.yy: load_data: Let us use TABLE_LIST::lock_type for passing type of lock for target table to mysql_load() instead of using LEX::lock_option (which will be rewritten by first subselect in SET clause).
ec919d74