Guang Bao,
> Hello Andrei,
>
> And I found the statement in manual.
> "The SET statement in stored routines is implemented as part of the
> pre-existing SET syntax. This allows an extended syntax of
> SET a=x, b=y, ... where different variable types (locally declared
> variables and global and session server variables) can be
> mixed. This also allows combinations of local variables and some
> options that make sense only for system variables; in that case,
> the options are recognized but ignored."
Perhaps ignored, indeed. Still, I think you would agree, with adding a
test where set @@session.sql_log_bin is done in a substatement would
make us comfortable.
cheers,
Andrei
>
> This means the options will be ignored, right?
>
> Thanks,
> /Guangbao
>
>> Hello Andrei,
>>
>> Thanks for your reivew.
>>
>> Replied inline below.
>>
>> Best wishes,
>> /Guangbao
>>
>> Andrei Elkin Wrote:
>>> Guang Bao, hello.
>>>
>>> Thanks for addressing last review notes.
>>> The new patch looks fine except it seems there exists one issue.
>>>
>>>
>>>> #At file:///home/gni/mysql/bzr/bugteam-5.1-bug41980/
>>>>
>>>> 2827 Guangbao Ni 2009-02-26
>>>> BUG#41980 SBL, INSERT .. SELECT .. LIMIT = ERROR, even when
>>>> @@SQL_LOG_BIN is 0 !
>>>> When binlog_format is STATEMENT and the statement is
>>>> unsafe before,
>>>> the unsafe warning/error message was issued without checking
>>>> whether the SQL_LOG_BIN was turned on or not.
>>>> Fixed with adding a sql_log_bin_toplevel flag in THD
>>>> to check
>>>> whether SQL_LOG_BIN is ON in current session whatever the
>>>> current is in sp or not.
>>>> modified:
>>>> mysql-test/suite/binlog/r/binlog_unsafe.result
>>>> mysql-test/suite/binlog/t/binlog_unsafe.test
>>>> sql/set_var.cc
>>>> sql/sql_class.cc
>>>> sql/sql_class.h
>>>>
>>>> per-file messages:
>>>> mysql-test/suite/binlog/r/binlog_unsafe.result
>>>> Test case result for unsafe warning/error message
>>>> mysql-test/suite/binlog/t/binlog_unsafe.test
>>>> Test case for unsafe message warning/error
>>>> sql/set_var.cc
>>>> Adding a function set_option_log_bin_bit() which specailly
>>>> handles to
>>>> the change of SQL_LOG_BIN bit in order to set sql_log_bin_toplevel
>>>> according to SQL_LOG_BIN current value at the same time.
>>>> sql/sql_class.cc
>>>> Initialize the flag sql_log_bin_toplevel in THD::init(),
>>>> and add the condition to check whether unsafe warning/error
>>>> message was issued.
>>>> sql/sql_class.h
>>>> Add a sql_log_bin_toplevel flag in THD to indicate whether the
>>>> toplevel SQL_LOG_BIN is on
>>>>
>>>
>>> ...
>>>
>>>
>>>> @@ -2963,6 +2964,15 @@ static bool set_option_bit(THD *thd, set
>>>> return 0;
>>>> }
>>>> +/*
>>>> + Functions to be only used to update thd->options OPTION_BIN_LOG
> bit
>>>> +*/
>>>> +static bool set_option_log_bin_bit(THD *thd, set_var *var)
>>>> +{
>>>> + set_option_bit(thd, var);
>>>> + thd->sql_log_bin_toplevel= thd->options & OPTION_BIN_LOG;
>>>> + return 0;
>>>> +}
>>>>
>>>
>>> Could you please make it sure that a query
>>>
>>> set @@sql_log_bin = val
>>>
>>> when done in a substatement won't change the new
>>> thd->sql_log_bin_toplevel?
>>>
>> Yes. I have tested it, the set @@sql_log_bin = val statement only
>> function in NON-substatement.
>> Need I add the test case for it in test file?
>>
>>> cheers,
>>>
>>> Andreiat
>>>
>>
>>
