From 3fa437cf4061c20f2995e859b89a6898d3b646b4 Mon Sep 17 00:00:00 2001 From: Alexander Nozdrin Date: Sat, 13 Nov 2010 18:05:02 +0300 Subject: Fix for Bug#56934 (mysql_stmt_fetch() incorrectly fills MYSQL_TIME structure buffer). This is a follow-up for WL#4435. The bug actually existed not only MYSQL_TYPE_DATETIME type. The problem was that Item_param::set_value() was written in an assumption that it's working with expressions, i.e. with basic data types. There are two different quick fixes here: a) Change Item_param::make_field() -- remove setting of Send_field::length, Send_field::charsetnr, Send_field::flags and Send_field::type. That would lead to marshalling all data using basic types to the client (MYSQL_TYPE_LONGLONG, MYSQL_TYPE_DOUBLE, MYSQL_TYPE_STRING and MYSQL_TYPE_NEWDECIMAL). In particular, that means, DATETIME would be sent as MYSQL_TYPE_STRING, TINYINT -- as MYSQL_TYPE_LONGLONG, etc. That could be Ok for the client, because the client library does reverse conversion automatically (the client program would see DATETIME as MYSQL_TIME object). However, there is a problem with metadata -- the metadata would be wrong (misleading): it would say that DATETIME is marshaled as MYSQL_TYPE_DATETIME, not as MYSQL_TYPE_STRING. b) Set Item_param::param_type properly to actual underlying field type. That would lead to double conversion inside the server: for example, MYSQL_TIME-object would be converted into STRING-object (in Item_param::set_value()), and then converted back to MYSQL_TIME-object (in Item_param::send()). The data however would be marshalled more properly, and also metadata would be correct. This patch implements b). There is also a possibility to avoid double conversion either by clonning the data field, or by storing a reference to it and using it on Item::send() time. That requires more work and might be done later. --- mysql-test/t/ps.test | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'mysql-test/t/ps.test') diff --git a/mysql-test/t/ps.test b/mysql-test/t/ps.test index bf15648951b..eaef1cf3000 100644 --- a/mysql-test/t/ps.test +++ b/mysql-test/t/ps.test @@ -3296,6 +3296,12 @@ SELECT @a; DROP PROCEDURE p1; DROP PROCEDURE p2; +########################################################################### + +--source t/wl4435_generated.inc + +########################################################################### + --echo --echo # End of WL#4435. -- cgit v1.2.1 From 7117e0635c60f5db23ebb0f4b0866ce93b8ffaed Mon Sep 17 00:00:00 2001 From: Alexander Nozdrin Date: Tue, 22 Mar 2011 14:48:56 +0300 Subject: A patch for Bug#11763413 (56115: SELECT doesn't work in prepared statements with cursor protocol). The problem was a bug in Materialized-cursor implementation. Materialized_cursor::open() called send_result_metadata() with items pointing to already closed table. The fix is to send metadata when the table is still open. NOTE: this is a "partial" fix: metadata are different with and without --cursor-protocol, but that's a different large problem, one indication of which is reported as Bug 24176. --- mysql-test/t/ps.test | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) (limited to 'mysql-test/t/ps.test') diff --git a/mysql-test/t/ps.test b/mysql-test/t/ps.test index eaef1cf3000..e00bd785789 100644 --- a/mysql-test/t/ps.test +++ b/mysql-test/t/ps.test @@ -3344,7 +3344,21 @@ connection default; DROP TABLE t1; disconnect con1; +--echo +--echo # +--echo # Bug#56115: invalid memory reads when PS selecting from +--echo # information_schema tables +--echo # Bug#58701: crash in Field::make_field, cursor-protocol +--echo # +--echo # NOTE: MTR should be run both with --ps-protocol and --cursor-protocol. +--echo # +--echo + +SELECT * +FROM (SELECT 1 UNION SELECT 2) t; + + --echo # ---echo # End of 6.0 tests. +--echo # End of 5.5 tests. ########################################################################### -- cgit v1.2.1