-
unknown authored
BETWEEN was more lenient with regard to what it accepted as a DATE/DATETIME in comparisons than greater-than and less-than were. ChangeSet makes < > comparisons similarly robust with regard to trailing garbage (" GMT-1") and "missing" leading zeros. Now all three comparators behave similarly in that they throw a warning for "junk" at the end of the data, but then proceed anyway if possible. Before < > fell back on a string- (rather than date-) comparison when a warning-condition was raised in the string-to-date conversion. Now the fallback only happens on actual errors, while warning- conditions still result in a warning being to delivered to the client. mysql-test/r/select.result: Show that we compare DATE/DATETIME-like strings as date(time)s now, rather than as bin-strings. Adjust older result as "2005-09-3a" is now correctly seen as "2005-09-3" + trailing garbage, rather than as "2005-09-30". mysql-test/t/select.test: Show that we compare DATE/DATETIME-like strings as date(time)s now, rather than as bin-strings. sql-common/my_time.c: correct/clarify date-related comments, particulary for check_date(). doxygenize comment while at it. sql/item_cmpfunc.cc: get_date_from_str() no longer signals an error when all we had was a warning-condition -- and one we already gave the user a warning for at that. Preamble doxygenized.
ac3ef6c7