Re: bk commit into 6.0 tree (malff:1.2644) BUG#36457

[Davi Arnaut]

Hi Marc,

Thanks for the detailed explanation, patch approved.

-- 
Davi Arnaut

Marc Alff wrote:
> Hi Davi
> 
> 
> Davi Arnaut wrote:
>> Hi Marc,
>>
>>
>> marc.alff@stripped wrote:
>>
>> [..]
>>
>>   
>>> diff -Nrup a/sql/my_decimal.cc b/sql/my_decimal.cc
>>> --- a/sql/my_decimal.cc	2007-10-11 11:29:06 -06:00
>>> +++ b/sql/my_decimal.cc	2008-05-13 17:42:38 -06:00
>>> @@ -41,7 +41,7 @@ int decimal_operation_results(int result
>>>  			"", (long)-1);
>>>      break;
>>>    case E_DEC_OVERFLOW:
>>> -    push_warning_printf(current_thd, MYSQL_ERROR::WARN_LEVEL_ERROR,
>>> +    push_warning_printf(current_thd, MYSQL_ERROR::WARN_LEVEL_WARN,
>>>                          ER_TRUNCATED_WRONG_VALUE,
>>>                          ER(ER_TRUNCATED_WRONG_VALUE),
>>>  			"DECIMAL", "");
>>>     
>> How this will be elevated to a error when sql_mode is set to
>> strict_all_tables (traditional)? or, shouldn't we also enforce the
>> traditional mode on selects too?
>>
>>   
> Please note that this bug report, and the patch, is not about SQL_MODE,
> and that no logic involving SQL_MODE is changed here.
> 
> To answer your question, when the 'strict_all_tables' mode is in effect:
> - the code in my_decimal.c calls push_warning_printf(WARN_LEVEL_WARN)
> - push_warning_printf() calls push_warning()
> - in push_warning, thd->really_abort_on_warning() will return TRUE,
> so that the push_warning() implementation internally change the level to 
> error and calls my_error().
> 
> This is how the strict mode is implemented today, I am explaining it, 
> not defending it.
> 
> THD::really_abort_on_warning() depends on:
> (a) - THD::abort_on_warning
> (b) - THD::transaction.stmt.modified_non_trans_table
> (c) - THD::variable.sql_mode & MODE_STRICT_ALL_TABLES
> 
> (a) is set only for some -- not all -- statements
> (b) relates to MODE_STRICT_TRANS_TABLES
> (c) is MODE_STRICT_ALL_TABLES
> 
> Should the traditional mode be enforced on selects also ?
> That depends on the semantic of this mode:
> 
> 'strict' modes are *not* used to protect the execution of any SQL statement,
> so the semantic is not comparable to, for example, "gcc -Wall -Werr".
> 
> ' strict' modes are used to protect the *data* in a table, and are 
> enforced only when data is written to a table.
> This is why THD::abort_on_warning is set only in a few places, in 
> sql_insert.cc, sql_update.cc, etc.
> 
> ... so no, strict modes should not be enforced during a SELECT, given 
> the current definition of this mode.
> 
> This topic is the subject of long debates every 2 years or so, and 
> traces back to very old history in mysql.
> 
> For example, see bug#5929, "to be fixed later", which was to be fixed in 
> 5.1, then in 5.2 ...
> 
> Best Regards,
> Marc.