mirror of
https://github.com/MariaDB/server.git
synced 2025-01-18 13:02:28 +01:00
4355ea5a38
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''
|
||
|---|---|---|
| .. | ||
| 14897.frm | ||
| bug15328.cnf | ||
| bug16266.000001 | ||
| des_key_file | ||
| init_file.dat | ||
| loaddata1.dat | ||
| loaddata2.dat | ||
| loaddata3.dat | ||
| loaddata4.dat | ||
| loaddata5.dat | ||
| loaddata_dq.dat | ||
| loaddata_pair.dat | ||
| master-bin.000001 | ||
| Moscow_leap | ||
| ndb_config_mycnf1.cnf | ||
| ndb_config_mycnf2.cnf | ||
| rpl_loaddata.dat | ||
| rpl_loaddata2.dat | ||
| rpl_timezone.dat | ||
| trunc_binlog.000001 | ||
| untrusted-cacert.pem | ||
| vchar.frm | ||
| warnings_loaddata.dat | ||
| words.dat | ||