mirror of
https://github.com/MariaDB/server.git
synced 2025-01-20 22:12:30 +01:00
3bf609b7f2
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. |
||
|---|---|---|
| .. | ||
| 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 | ||