Fixing the asymmetry in the array field_types_merge_rules[][]
which caused data loss when mixing FLOAT + BIGINT in UNIONs
or hybrid functions:
1. FLOAT + INT = DOUBLE
2. FLOAT + BIGINT = FLOAT
3. INT + FLOAT = DOUBLE
4. BIGINT + FLOAT = DOUBLE
Now FLOAT + BIGINT (as in #2) also produces DOUBLE, like the cases #1,#3,#4 do.
- Fix win64 pointer truncation warnings
(usually coming from misusing 0x%lx and long cast in DBUG)
- Also fix printf-format warnings
Make the above mentioned warnings fatal.
- fix pthread_join on Windows to set return value.
Implement Field_timestamp::save_in_field(timestamp_field)
that stores timestamp values without converting them to MYSQL_TIME
and back, because this conversion is lossy around DST change time.
This fixes main.old-mode test.
This is 10.2 version of f8a800bec8
make insert NULL into a timestamp mark the field as having an
explicit value. So that the field won't be assigned the value
again in TABLE::update_default_field()
make Item_func_now_local::save_in_field(timestamp_field) not to go
through MYSQL_TIME - this conversion is lossy around DST change times.
This fixes inserting a default value into a timestamp field.
Backport of 7e29f2d64f from 10.1.
Create_field does not set BINARY_FLAG, so the check didn't work at all.
Also, character sets were already compared, so this check would've been
redundant (if it would've worked).
Do not silence uncertain cases, or fix any bugs.
The only functional change should be that ha_federated::extra()
is not calling DBUG_PRINT to report an unhandled case for
HA_EXTRA_PREPARE_FOR_DROP.
Do not silence uncertain cases, or fix any bugs.
The only functional change should be that ha_federated::extra()
is not calling DBUG_PRINT to report an unhandled case for
HA_EXTRA_PREPARE_FOR_DROP.
Optionally do table->update_default_fields() even for INSERT
that supposedly provides values for all column. Because these
"values" might be DEFAULT, which would need table->update_default_fields()
at the end.
Also set Item_default_value::used_tables() from the default expression.
Non-zero used_field() means that mysql_insert() will initialize all
fields to their default values (with restore_record()) even if
all columns are later provided with values. Because default expressions
may refer to other columns and they must be initialized.
- Put back the assert on SQL layer at the right location
- Adjust rdb_pack_with_make_sort_key to work around the assert (like
it is done at other palaces): MyRocks may need to pack a column
value even when the column is not in the read set.
Found and fixed 2 problems:
- Filesort addon fields didn't mark virtual columns properly
- multi-range-read calculated vcol bitmap but was not using it.
This caused wrong vcol field to be calculated on read, which caused the assert.
otherwise we'd need to store sql_mode *per vcol*
(consider CREATE INDEX...) and how SHOW CREATE TABLE would
support that?
Additionally, get rid of vcol::expr_str, just to make sure
the string is always generated and never leaked in the
original form.
Backport the fix for BUG#81810 from facebook/mysql-5.6 tree.
Added the original testcase.
rocksdb.type_text_indexes still fails due to another problem.
ISSUE: Heap corruption occurs and hence mysql server
terminates abnormally in String variable destructor
when ZEROFILL is used for a column.
Though the abnormal termination is observed in the
String destructor, heap corruption occurs at earlier
stage when function Field_num::prepend_zeros() is called.
This function, prepends zeros to the actual data and
works on entire field length. Since the allocated memory
could be less than the field length, heap corruption occurs.
Later, when String destructor tries to free heap, the server
terminates abnormally since the heap is corrupt.
SOLUTION: In Field_num::prepend_zeros() function, if allocated memory
is less than the field length, re-allocate memory enough to
hold field length size data.
