A fix for Bug#14897 "ResultSet.getString("table.column") sometimes
doesn't find the column" When a user was using 4.1 tables with VARCHAR column and 5.0 server and a query that used a temporary table to resolve itself, the table metadata for the varchar column sent to client was incorrect: MYSQL_FIELD::table member was empty. The bug was caused by implicit "upgrade" from old VARCHAR to new VARCHAR hard-coded in Field::new_field, which did not preserve the information about the original table. Thus, the field metadata of the "upgraded" field pointed to an auxiliary temporary table created for query execution. The fix is to copy the pointer to the original table to the new field. mysql-test/r/type_varchar.result: Update test results (Bug#14897) mysql-test/t/type_varchar.test: Add a test case for Bug#14897 "ResultSet.getString("table.column") sometimes doesn't find the column" sql/field.cc: Preserve the original table name when converting fields from old VARCHAR to new VARCHAR. mysql-test/std_data/14897.frm: New BitKeeper file ``mysql-test/std_data/14897.frm''
Showing
This diff was suppressed by a .gitattributes entry.
Please register or sign in to comment