The change N7 in MDEV-15340 (see the commit message) introduced
a regression in how CAST(AS TIME), HOUR(), TIME_TO_SEC() treat datetimes
'0000-00-DD mm:hh:ss' (i.e. with zero YYYYMM part and a non-zero day).
These functions historically do not mix days to hours on datetime-to-time
conversion. Implementations of the underlying methods used get_arg0_time()
to fetch MYSQL_TIME. After MDEV-15340, get_arg0_time() went through the
Time() constructor, which always adds '0000-00-DD' to hours automatically
(as in all other places in the code we do mix days to hours).
Changes:
1. Extending Time() to make it possible to choose a desired way of treating
'0000-00-DD' (ignore or mix to hours) on datetime-to-time conversion.
Adding a helper class Time::Options for this, which now describes two aspects
of Time() creation:
1. Flags for get_date()
2. Days/hours mixing behavior.
2. Removing Item_func::get_arg0_time(). Using Time() directly
in all affected classes. Forcing Time() to ignore (rather than mix)
'0000-00-DD' in these affected classes by passing a suitable Options value.
3. Adding Time::to_seconds(), to reuse the code between
Item_func_time_to_sec::decimal_op() and Item_func_time_to_sec::int_op().
4. Item_func::get_arg0_date() now returns only a datetime value,
with automatic time-to-datetime conversion if needed. An assert was
added to catch attempts to pass TIME_TIME_ONLY to get_arg0_date().
All callers were checked not to pass TIME_TIME_ONLY, this revealed
a bug MDEV-15363.
5. Changing Item_func_last_day::get_date() to remove the TIME_TIME_ONLY flag
before calling get_arg0_date(). This fixes MDEV-15363.
The problem was that Item_func_hybrid_field_type::get_date() did not
convert the result to the correct data type, so MYSQL_TIME::time_type
of the get_date() result could be not in sync with field_type().
Changes:
1. Adding two new classes Datetime and Date to store MYSQL_TIMESTAMP_DATETIME
and MYSQL_TIMESTAMP_DATE values respectively
(in addition to earlier added class Time, for MYSQL_TIMESTAMP_TIME values).
2. Adding Item_func_hybrid_field_type::time_op().
It performs the operation using TIME representation,
and always returns a MYSQL_TIME value with time_type=MYSQL_TIMESTAMP_TIME.
Implementing time_op() for all affected children classes.
3. Fixing all implementations of date_op() to perform the operation
using strictly DATETIME representation. Now they always return a MYSQL_TIME
value with time_type=MYSQL_TIMESTAMP_{DATE|DATETIME},
according to the result data type.
4. Removing assignment of ltime.time_type to mysql_timestamp_type()
from all val_xxx_from_date_op(), because now date_op() makes sure
to return a proper MYSQL_TIME value with a good time_type (and other member)
5. Adding Item_func_hybrid_field_type::val_xxx_from_time_op().
6. Overriding Type_handler_time_common::Item_func_hybrid_field_type_val_xxx()
to call val_xxx_from_time_op() instead of val_xxx_from_date_op().
7. Modified Item_func::get_arg0_date() to return strictly a TIME value
if TIME_TIME_ONLY is passed, or return strictly a DATETIME value otherwise.
If args[0] returned a value of a different temporal type,
(for example a TIME value when TIME_TIME_ONLY was not passed,
or a DATETIME value when TIME_TIME_ONLY was passed), the conversion
is automatically applied.
Earlier, get_arg0_date() did not guarantee a result in
accordance to TIME_TIME_ONLY flag.
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.
This should also fix the MariaDB 10.2.2 bug
MDEV-13826 CREATE FULLTEXT INDEX on encrypted table fails.
MDEV-12634 FIXME: Modify innodb-index-online, innodb-table-online
so that they will write and read merge sort files. InnoDB 5.7
introduced some optimizations to avoid using the files for small tables.
Many collation test results have been adjusted for MDEV-10191.
The problem was introduced by the patch for MDEV-7661,
which (in addition to the fix itself) included an attempt to make
CONVERT/CAST work in the same way with fields
(i.e. return NULL in strict mode if a non-convertable character found).
It appeared to be a bad idea and some users were affected by this
behavior change. Changing CONVERT/CAST not depend on sql_mode
(restoring pre-10.1.4 behavior).
CID 971836 (#1 of 1): Same on both sides (CONSTANT_EXPRESSION_RESULT)
pointless_expression: The expression val != end && val != end does not
accomplish anything because it evaluates to either of its identical
operands, val != end.
- Adding a new virtual method Type_handler::Item_time_precision()
- Adding a new virtual method Type_handler::Item_datetime_precision()
- Removing Item::temporal_precision() and adding Item::time_precision()
and Item::datetime_precision() instead.
- Moving Item_func_convert_tz::fix_length_and_dec() from item_timefunc.cc
to item_timefunc.h. It's only two lines, and we're changing it anyway.
- Removing Item_temporal_typecast::fix_length_and_dec_generic(),
moving this code to
Type_handler::Item_{date|time|datetime}_typecast_fix_length_and_dec().
This allows to get rid of one more field_type() call.
Also, in the old reduction, Item_date_typecast::fix_length_and_dec()
unnecessarily called args[0]->temporal_precision(). The new reduction
does not call args[0]->datetime_precision(), as DATE does not
have fractional digits.
This patch implements MDEV-12514 according to the task descriptions.
It automatically fixes:
MDEV-12515 Wrong value when storing DATE_ADD() and ADDTIME() to a numeric field
Additionally:
a. Moves Item_func::set_attributes_temporal() to
Type_str_attributes::fix_attributes_temporal(),
which is a more proper place and name for it.
b. Continues replacing calls for:
set_handler_by_field_type(MYSQL_TYPE_XXX)
to corresponding:
set_handler(&type_handler_xxx)
which is faster.
Note, we should eventually get rid of almost all set_handler_by_field_type().
c. Makes type_handler_string, type_handler_time2, type_handler_newdate,
type_handler_datetime2 public.
(all built-in handlers will become public eventually)
d. Removing Item_temporal_func::sql_mode, as it was not used.
This change is a backport from 10.0 to 5.5 for:
1. The full patch for:
MDEV-4841 Wrong character set of ADDTIME() and DATE_ADD()
9adb6e991e
2. A small fragment of:
MDEV-5298 Illegal mix of collations on timestamp
03f6778d61
which overrides Item_temporal_hybrid_func::cmp_type(),
and adds a new line into cache_temporal_4265.result.
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.
MDEV-10134 Add full support for DEFAULT
- Added support for using tables with MySQL 5.7 virtual fields,
including MySQL 5.7 syntax
- Better error messages also for old cases
- CREATE ... SELECT now also updates timestamp columns
- Blob can now have default values
- Added new system variable "check_constraint_checks", to turn of
CHECK constraint checking if needed.
- Removed some engine independent tests in suite vcol to only test myisam
- Moved some tests from 'include' to 't'. Should some day be done for all tests.
- FRM version increased to 11 if one uses virtual fields or constraints
- Changed to use a bitmap to check if a field has got a value, instead of
setting HAS_EXPLICIT_VALUE bit in field flags
- Expressions can now be up to 65K in total
- Ensure we are not refering to uninitialized fields when handling virtual fields or defaults
- Changed check_vcol_func_processor() to return a bitmap of used types
- Had to change some functions that calculated cached value in fix_fields to do
this in val() or getdate() instead.
- store_now_in_TIME() now takes a THD argument
- fill_record() now updates default values
- Add a lookahead for NOT NULL, to be able to handle DEFAULT 1+1 NOT NULL
- Automatically generate a name for constraints that doesn't have a name
- Added support for ALTER TABLE DROP CONSTRAINT
- Ensure that partition functions register virtual fields used. This fixes
some bugs when using virtual fields in a partitioning function
UNIX_TIMESTAMP(STR_TO_DATE('201506', "%Y%M"
Issue:
-----
When an invalid date is supplied to the UNIX_TIMESTAMP
function from STR_TO_DATE, no check is performed before
converting it to a timestamp value.
SOLUTION:
---------
Add the check_date function and only if it succeeds,
proceed to the timestamp conversion.
No warning will be returned for dates having zero in
month/date, since partial dates are allowed. UNIX_TIMESTAMP
will return only a zero for such values.
The problem has been handled in 5.6+ with WL#946.
