- 12 Dec, 2016 40 commits
-
-
Sergei Golubchik authored
instead of returning strings for CASCADE/RESTRICT from every storage engine, use enum values
-
Sergei Golubchik authored
* wrong results for 5.7 and 10.1- vcols, and for indexed vcols * only helps in rare cases and only minimally
-
Sergei Golubchik authored
partitioning was setting subj as a partitioning-specific hack (GET_FIXED_FIELDS_FLAG field flag to detect partitioning fields) inside init_lex_with_single_table(). But vcols also use init_lex_with_single_table(), they run fix_fields() in open_table_from_share() before partitioning and this messes up partitioning GET_FIXED_FIELDS_FLAG logic.
-
Sergei Golubchik authored
When updating a table with virtual BLOB columns, the following might happen: - an old record is read from the table, it has no virtual blob values - update_virtual_fields() is run, vcol blob gets its value into the record. But only a pointer to the value is in the table->record[0], the value is in Field_blob::value String (but it doesn't have to be! it can be in the record, if the column is just a copy of another columns: ... b VARCHAR, c BLOB AS (b) ...) - store_record(table,record[1]), old record now is in record[1] - fill_record() prepares new values in record[0], vcol blob is updated, new value replaces the old one in the Field_blob::value - now both record[1] and record[0] have a pointer that points to the *new* vcol blob value. Or record[1] has a pointer to nowhere if Field_blob::value had to realloc. To resolve this we unlink vcol blobs from the pointer to the data (in the record[1]). Because the value is not *always* in the Field_blob::value String, we need to remember what blobs were unlinked. The orphan memory must be freed manually. To complicate the matter, ha_update_row() is also used in multi-update, in REPLACE, in INSERT ... ON DUPLICATE KEY UPDATE, also on REPLACE ... SELECT, REPLACE DELAYED, and LOAD DATA REPLACE, etc
-
Sergei Golubchik authored
multi-update was setting up read_set/vcol_set in multi_update::initialize_tables() that is invoked after the optimizer (JOIN::optimize_inner()). But some rows - if they're from const tables - will be read already in the optimizer, and these rows will not have all necessary column/vcol values. * multi_update::initialize_tables() uses results from the optimizer and cannot be moved to be called earlier. * multi_update::prepare() is called before the optimizer, but it cannot set up read_set/vcol_set, because the optimizer might reset them (see SELECT_LEX::update_used_tables()). As a fix I've added a new method, select_result::prepare_to_read_rows(), it's called from inside the optimizer just before make_join_statistics().
-
Sergei Golubchik authored
This fixes a bug where handler::read_range_first (for example) needed to compare vcol values that were not calculated yet. As a bonus it fixes few cases where vcols were calculated twice
-
Sergei Golubchik authored
sql_insert.cc calls handler->ha_update_row() for REPLACE and INSERT... ON DUPLICATE KEY UPDATE
-
Sergei Golubchik authored
-
Sergei Golubchik authored
cannot use TABLE:merge_keys for that, because Field::part_of_key was designed to mark fields for KEY_READ, so a field is not a "part of key", if only prefix of the field is.
-
Sergei Golubchik authored
* don't issue an error for ER_KEY_BASED_ON_GENERATED_VIRTUAL_COLUMN * support keyread on vcols * callback into the server to compute vcol values from mi_check/mi_repair * DMLs just work. Automatically.
-
Sergei Golubchik authored
update tests and results, fix bugs
-
Sergei Golubchik authored
-
Sergei Golubchik authored
will be used later by storage engines (e.g. in MyISAM repair or in InnoDB purge)
-
Sergei Golubchik authored
because it's only doing to show the table structure, not look at the data.
-
Sergei Golubchik authored
-
Sergei Golubchik authored
always set them according to the repair method used
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Sergei Golubchik authored
and declare few other Field getters to be 'const'
-
Sergei Golubchik authored
Make update_virtual_fields() a method of TABLE, to be consistent with TABLE::update_default_fields().
-
Sergei Golubchik authored
TABLE::mark_virtual_col() was polluting table->vcol_set and that confused the following mark_virtual_col()
-
Sergei Golubchik authored
-
Sergei Golubchik authored
make it to work when read_set == vcol_set, that is, when the caller wants to get a one complete bitmap of all fields a particular vcol depends on.
-
Sergei Golubchik authored
it was done only in some access methods, not in all, so the caller had to update_virtual_fields anyway.
-
Sergei Golubchik authored
-
Sergei Golubchik authored
In spatial indexes there can be only one keyseg. Make it explicit in the code, don't pretend that this can work with the arbitrary number of keysegs.
-
Sergei Golubchik authored
-
Sergei Golubchik authored
and FIELDFLAG_xxx constants
-
Sergei Golubchik authored
prefer x->field over table->field[x->field->field_index]
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Sergei Golubchik authored
only use my_print_error when the error message is not ER(error_code)
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Sergei Golubchik authored
the stage is changed from 'old_stage' to 'new_stage', not the other way around
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-