BUG#18326: Do not lock table for writing during prepare of statement

During statement prepare phase the tables were locked as if the
statement is being executed, however this is not necessary.

The solution is to not lock tables on statement prepare phase.
Opening tables is enough to prevent DDL on them, and during statement
prepare we do not access nor modify any data.


mysql-test/r/ps.result:
  Add result for bug#18326: Do not lock table for writing during
  prepare of statement.
mysql-test/t/ps.test:
  Add test case for bug#18326: Do not lock table for writing during
  prepare of statement.
sql/sql_prepare.cc:
  Do not lock tables on statement prepare phase.  Opening tables is
  enough to prevent DDL on them, and during statement prepare we do not
  access nor modify any data.
  
  Use open_normal_and_derived_tables() for table opening on prepare.

1 files changed, 37 insertions, 0 deletions

diff --git a/mysql-test/r/ps.result b/mysql-test/r/ps.result
index a99fdb16868..e2037e6e87e 100644
--- a/mysql-test/r/ps.result
+++ b/mysql-test/r/ps.result
@@ -2488,3 +2488,40 @@ execute stmt2 using @to_format, @dec;
 format(?, ?)
 10,000.00
 deallocate prepare stmt2;
+DROP TABLE IF EXISTS t1, t2;
+CREATE TABLE t1 (i INT);
+INSERT INTO t1 VALUES (1);
+CREATE TABLE t2 (i INT);
+INSERT INTO t2 VALUES (2);
+LOCK TABLE t1 READ, t2 WRITE;
+PREPARE stmt1 FROM "SELECT i FROM t1";
+PREPARE stmt2 FROM "INSERT INTO t2 (i) VALUES (3)";
+EXECUTE stmt1;
+i
+1
+EXECUTE stmt2;
+SELECT * FROM t2;
+i
+2
+UNLOCK TABLES;
+SELECT * FROM t2;
+i
+2
+3
+ALTER TABLE t1 ADD COLUMN j INT;
+ALTER TABLE t2 ADD COLUMN j INT;
+INSERT INTO t1 VALUES (4, 5);
+INSERT INTO t2 VALUES (4, 5);
+EXECUTE stmt1;
+i
+1
+4
+EXECUTE stmt2;
+SELECT * FROM t2;
+i	j
+2	NULL
+3	NULL
+4	5
+3	NULL
+DROP TABLE t1, t2;
+End of 5.1 tests.