Mats Kindahl <mats@stripped> writes:
>> @@ -3253,6 +3253,7 @@ f1 f2
>> 5 2005-12-30
>> select * from t1 where f2 >= '2005-09-3a';
>> f1 f2
>> +3 2005-09-30
>> 4 2005-10-01
>> 5 2005-12-30
>> Warnings:
>> @@ -3266,7 +3267,6 @@ select * from t1 where f2 <= '2005-09-3a
>> f1 f2
>> 1 2005-01-01
>> 2 2005-09-01
>> -3 2005-09-30
>
> Add an ORDER BY to the SELECT to avoid getting them in different orders.
That's an old test, but yeah, no reason we can't make it better
while we're at it, I guess. Good point. Thanks!
>> + @param[out] was_cut != 0 if clipping did occur, cf. str_to_datetime()
>> + @param[out] was_type the type we managed to extract
>> +
>> */
>> static ulonglong
>> get_date_from_str(THD *thd, String *str, timestamp_type warn_type,
>> - char *warn_name, bool *error_arg)
>> + char *warn_name, int *was_cut, timestamp_type *was_type)
>>
>
> Since these output parameters are all booleans
They're not.
- return is the long representation of the DATETIME where 0 has
in-band meaning. 0 is also returned on failure, but that's why
we need the type to distinguish between garbage-input and a
null-date.
- was_cut is passed through from str_to_datetime() (and in some
cases, check_date()) and is documented as being one of 0;1;2.
- was_type is an enum_mysql_timestamp_type.
>> + timestamp_type was_type;
>> + int was_cut;
>> + value= get_date_from_str(thd, str, t_type, warn_item->name,
>> + &was_cut, &was_type);
>>
>
> Since these are not used, it could be a good idea to allow NULL to
> be given to the function and only update the variable if it is
> non-null.
I actually considered that for a moment when I wrote it, so I
certainly don't have strong enough feelings about this to go to
war about it. I ended up figuring, it's two lines either way
(two ifs, or two defintions), and I didn't want to make ignoring
the diagnostics /too/ easy. : ) (Wouldn't give it much thought
otherwise, but we have a lot of legacy stuff where functions
return arbitrary-seeming values -- no #defines, not enums, no
preamble explaining the values, and once a function's callees
are overloaded or called via function pointers, you get a ton of
extra fun trying to work out what could be returned, and what
those values mean. And look at this patch. Almost the entire
ChangeSet is about fixing a wrapper that was 50 % about taking
perfectly good diagnostics and mangling them into something
useless.) But given that we return sensible stuff now, and have
a preamble that explains what that might be, I'm good either way.
(Adjusted, attached.)
thanks and regards,
-A-
--
Tatjana A. Nurnberg, Bugs Bunny * MySQL AB, http://www.mysql.de/ * EST
IRC: Azundris * Skype: azundris * MySQL-SIP: 4550 * eMail: azundris@stripped
.de: Firmensitz: MySQL GmbH, Radlkoferstr. 2, D-81373 Muenchen
Geschaeftsfuehrer: Hans von Bell, Kaj Arnoe - HRB Muenchen 162140
